Sarah Fluchs
Nach ihrem Maschinenbaustudium hat Sarah Fluchs den Weg in die Cybersecurity gefunden. Heute ist sie CTO bei admeritia und hat gerade als Mitautorin die „Top 20 Secure Coding Practices“ für SPS-Programmierung veröffentlicht. In unserem Exklusivinterview spricht sie über knifflige Herausforderung in ihrer Arbeit, technischen Entwicklungen im Bereich OT-/IoT-Security und gibt Tipps, wie sich Geschäftsführer von KMUs der OT-Security nähern können.
Liebe Frau Fluchs, wie sind Sie eigentlich auf das Thema industrielle Cybersecurity gekommen?
Kurze Antwort: Weil ich immer ein Fachgebiet gesucht habe, bei dem man das ganze System und nicht „nur“ einen kleinen, durchoptimierten Teil im Blick haben darf und muss.
Lange Antwort: Im Maschinenbaustudium konnte ich mich nie so recht für eine Fachrichtung entscheiden. Warum sollte eine Art Maschine oder ein Anlagenteil interessanter sein als ein anderer? „Kommen Sie zu uns, wir bauen mathematische Modelle des Gesamtsystems“, sagte dann ein Regelungstechnik-Professor – das klang einleuchtend, und Systemtheorie und Modellbildung fand ich faszinierend. Mein Problem ist nur, dass ich immer mehr Spaß am Systeme-Verstehen als am Systeme-Bauen hatte. Mein ganzes Leben lang Regler zu optimieren konnte ich mir nur schwer vorstellen. Blut geleckt habe ich dann, als es im sehr interdisziplinären Automatisierungstechnikmaster viel um Kommunikationstechnik ging (und dort am Rande auch um Security). Da habe ich verstanden: In der Security geht das beides, erstens das ganze System im Blick haben, zweitens ständig neue Systeme verstehen dürfen, die man nicht selbst ausgelegt hat. Nebenbei habe ich damals journalistisch gearbeitet und zum Thema Datensicherheit und Privacy eine längere Reportage geschrieben – damit stand das Thema für die Masterarbeit fest. Dass es so etwas wie Security für Automatisierungstechnik auch gibt, habe ich dann zufällig bei der Suche nach Masterarbeitsthemen beim Bundesamt für Sicherheit in der Informationstechnik (BSI) festgestellt. Damit war klar: Da muss ich hin. Vor allem, weil das ein noch relativ unbeackertes Forschungsgebiet war, eines mit noch viel sehr grundlegendem Gestaltungsspielraum. Das ist auch jetzt noch so.
Und: interdisziplinärer geht es fast nicht. Automatisierungstechnik ist an sich schon interdisziplinär und branchenübergreifend, in der industriellen Security kommt noch ganz viel Netzwerktechnik und Informatik dazu, aber auch viele aus Ingenieursicht „weiche“ Disziplinen wie Management, Organisationsstrukturen und sogar Psychologie.
Gibt es eine Anekdote oder Geschichte aus Ihrem Berufsleben, die vielleicht noch nicht (oder nicht oft genug) erzählt wurde?
Ich kann recht überzeugt sagen, dass ich studiert habe, wozu ich am allerwenigsten Talent hatte.
Ein Ingenieurstudium stand eigentlich so gar nicht auf meiner Agenda. Physik hatte ich in der Schule abgewählt, und ich war wahrscheinlich der einzige Maschinenbau-Erstsemester in Aachen, der in der Physikvorlesung das erste Mal in seinem Leben von einem „Newton“ gehört hat.
Vor dem Maschinenbaustudium hatte ich zwei Semester Mathematik studiert. Das habe ich abgebrochen. Der Grund: Mathe war mir zu eng. „Maschinenbau“ ist ja eigentlich ein völlig irreführender Titel, eigentlich sollte es „Studium generale der Naturwissenschaften“ heißen.
An der RWTH Aachen musste man damals vor der Einschreibung zum Maschinenbaustudium ein freiwilliges Self-Assessment machen, mit Aufgaben zu Mathematik, Logik, technischem Verständnis und räumlichen Denken. Tja, das Self-Assessment hat mir nahegelegt, lieber Mathematik zu studieren…
Was sind typische Anfragen, mit denen Kunden heute auf Sie und Ihre Kollegen zugehen?
„Wir sind eigentlich ganz gut aufgestellt, aber…“.
Es ist weder eine Schande noch überraschend, wenn man sich in der Security gut aufgestellt fühlt – und ebensowenig ist es eine Schande oder überraschend, dann festzustellen, dass man das doch nicht ist.
Industrielle Security ist ein Thema, das die meisten Ingenieure nicht gelernt haben und die meisten Anlagen nicht in der Planung mitbekommen haben. Wie soll man da auch wissen, was a) „gut aufgestellt“ eigentlich bedeutet und b) wie das gehen soll?
Security ist ein oft unterschätztes Thema, weil es in der Compliance-Ecke angesiedelt wird. Security wird oft gleichgesetzt mit Informationssicherheitsmanagement, das ist so ähnlich wie Qualitätsmanagement – und Qualitätsmanagement ist oft auch so etwas, was man auf dem Papier hat und jeder weiß, dass es in der Realität anders läuft. Spannend (auch aus Ingenieurssicht) wird Security, wenn man sie wirklich aus technischer Sicht angeht: Was muss eigentlich genau laufen, damit „die Anlage läuft“?
„Wir wissen nicht, wo wir anfangen sollen…“
Siehe oben: Security Engineering als Disziplin, vor allem als Teildisziplin für automatisierte Anlagen, steckt noch immer in den Kinderschuhen. Ich verstehe daher Ingenieure gut, die von dem Thema nur noch genervt sind. Ständig sagt ihnen jemand, dass sie an die Security denken sollen – aber keiner sagt ihnen, wie. Aus Ingenieursicht, die sehr methodisches, oft modellgetriebenes, naturwissenschaftsnahes und dazu oft standardisiertes Vorgehen gewohnt ist, ist die methodische Armut der Security unverständlich bis frustrierend. Wo ist „der Dubbel“ für Security, wenn man ihn braucht?
Dazu kommt: Meistens haben Ingenieure das „Randthema“ Security nur als Extra-Rucksack zu ihren bestehenden Aufgaben dazu bekommen. Das heißt auch: Es wird erwartet, dass es in die Randstunden passt. Tut es aber oft nicht, wenn man es zufriedenstellend machen möchte. Es fehlt an Methodik, aber oft auch schlicht an der Datenbasis (Assetregister!) und der Zeit.
„Die Security-Menschen verstehen uns und unsere Anlagen nicht.“
Es passiert häufig, dass die IT der Automatisierung mit Unverständnis bis hin zu Arroganz begegnet:
- „Was ihr da macht, haben wir schon vor 20 Jahren abgeschafft!“
- „Industrial Ethernet ist doch auch Ethernet, so viel anders kann das doch nicht sein.“
Häufige Aussagen im Eifer des täglichen Gefechts.
Ebenso begegnet die Automatisierung der IT mit Unverständnis bis hin zu Arroganz:
„Wer noch nicht einmal SPS buchstabieren kann, muss mir nicht erzählen, wie ich meine Arbeit zu machen habe.“
Beide Sichtweisen sind nachvollziehbar, aber falsch. Beide Seiten können etwas voneinander lernen. Aber tendenziell gibt die Automatisierung zu viel an die IT ab. Security geht nicht ohne die Menschen, die die Systeme verstehen – nur müssen die sich für „ihre Security“ auch zuständig fühlen (und dazu in der Lage, das Thema in die Hand zu nehmen).
Was war eine besonders knifflige technische Herausforderung, die Sie und Ihr Team gelöst haben, und zu der Sie etwas erzählen können?
Eine aktuelle technische Herausforderung, die wir schon seit über einem Jahr mit einem internationalen Pharmakonzern lösen, ist eine technische Lösung für das Patchmanagement in den automatisierungsnahen Netzwerken zu konzeptionieren und auszurollen, die an allen Standorten weltweit funktioniert. Wir können guten Gewissens sagen: Wir kennen alle Lösungen dazu auf dem Markt. Keine ist perfekt. Es ist viel Drumherumgebastel notwendig – das man aber in einem weltweiten Konzern natürlich nicht haben möchte.
Das Problem hat drei Teilprobleme.
- Wie werde ich überhaupt über neue Patches informiert und wie komme ich an diese Patches?
- Wie entscheide ich, welches Patch überhaupt eingespielt werden muss – und wie schnell?
- Wie rolle ich Patches mit überschaubarem Aufwand und ohne Downtime auf Anlagen aus, die nicht alle vernetzt sind und die im Zweifel 24/7 laufen?
Man sieht also, dass das Thema Patchmanagement beileibe nicht nur ein technisches ist, und auch, warum es zwischen Security für „normale“ IT und den industriellen Bereich so große Unterschiede gibt. Nehmen wir beispielsweise die zweite Problemscheibe: IT’ler verstehen oft schon die Frage nicht. Ein Security-Patch wird eingespielt, und zwar so bald wie möglich. Ende der Diskussion.
In der Automatisierung kann aber informiertes Nicht-Patchen eine durchaus weise Entscheidung sein, und die Frage danach, was genau zu patchen ist, ist ein wichtiger (und der komplizierteste!) Bestandteil der Patch-Lösung. Zum Beispiel: Wenn Sie ein Security-Patch ausrollen, aber damit die Haftung des Leitsystemherstellers flöten geht, haben Sie nichts gewonnen. Die Haftungsfrage hängt aber oft von der genauen Softwarekombination ab, die auf einem System installiert ist – und diese Information müssen Sie erst einmal haben…
Sie haben ja gerade als Mitautorin die „Top 20 Secure Coding Practices“ für SPS-Programmierung veröffentlicht. Für die ungeduldigen Leser: Was sind 1-2 Beispiele dafür, SPSen sicherer zu programmieren?
Meine Lieblings-Practices sind immer solche, die die inhärenten Stärken einer SPS nutzen. Kein System im Feld kennt den Prozess besser als die SPS. Wenn man wissen will, ob eine Änderung im Prozess eine Anomalie ist – fragen Sie die SPS, kein Anomalieerkennungstool. Das bedeutet im Umkehrschluss auch, dass SPSen das wichtigste System, die last line of defense, für die Integritätsprüfung von übergebenen Sollwerten und Parametern sind – von den Feldgeräten und an die Feldgeräte.
Das kann man gezielt überprüfen. Ihr Sensor sagt Ihnen, das ein Ventil, das physisch 3 Sekunden braucht, um sich zu schließen, in einer Millisekunde geschlossen wurde? Fragen Sie die SPS, ob das Sinn ergibt. Das Leitsystem sagt der SPS, dass die dreifache Chemikalienmenge ab heute eine gute Idee ist? Fragen Sie die SPS, ob das wirklich eine gute Idee ist. SPSen können die Bodyguards ihres Prozesses sein.
Abgesehen vom schon sehr strapazierten Triton-Vorfall: Gibt es andere Beispiele für Cyberangriffe, bei denen SPS (aus-)genutzt wurden?
Wenn man ehrlich ist, gibt es insgesamt nur eine sehr überschaubare Anzahl von Angriffen dediziert auf industrielle IT. Der weitaus größere Teil sind Angriffe auf die IT, die beabsichtigte oder zufällige Seiteneffekte auf die Automatisierungstechnik hatten.
Angriffe gezielt auf Steuerungen sind aufwendig und erfordern Prozesskenntnisse. In der Regel sind das auch keine Angriffe direkt auf die Steuerungen, sondern Angriffe über Engineering-PCs (Stuxnet) oder das Leitsystem (Oldsmar).
Die Frage danach, ob nun direkt eine SPS angegriffen wurde oder nur indirekt, ist aber eigentlich weniger wichtig. Will man in der industriellen IT Auswirkungen auf den Prozess erreichen – und das sind in der Regel die absoluten Horrorszenarien, die wir vermeiden wollen – dann führt der Weg eben oft über die SPS. SPS-Schwachstellen sind bekannt, weit verbreitet, und manchmal sogar notwendige „Features“. Da war es notwendig, eine Diskussion darüber zu beginnen, was wir eigentlich unter „sicheren“ SPSen verstehen würden. Das sollen die Secure Coding Pratices leisten.
Um keine Missverständnisse aufkommen zu lassen: Secure Coding Practices für SPSen allein sind kein wirksamer Schutz vor solchen Vorfällen. Ich würde niemandem empfehlen, sie als allererste Maßnahme umzusetzen, wenn man sich sonst noch keine Gedanken um Security gemacht hat. Die Coding Practices sorgen dafür, dass die SPSen nicht mehr das schwächste Glied in der Kette sind, sondern im Zweifel eine weitere Schutzschicht: Von der Achillesferse der Anlage zum Anlagen-Bodyguard.
Welche technischen Entwicklungen im Bereich OT-/IoT-Security finden Sie aktuell besonders interessant?
Es gibt spannende Entwicklungen im Beschnuppern der Security- und Safety-Experten. In der OT landen wir immer mehr bei der Erkenntnis, dass wir eigentlich beide am gleichen, übergeordneten Ziel arbeiten: Der Resilienz von technischen Systemen gegenüber unvorhergesehenen Veränderungen von außen. Das zusammen in System-Engineering-Methoden zu gießen (ohne dabei Security und Safety methodisch zu vermengen und voneinander abhängig zu machen!) – das ist eine Mammutaufgabe. Aber in ein paar Jahren oder Jahrzehnten werden wir uns wundern, dass wir es nicht schon immer so gemacht haben.
Ein weiteres spannendes Thema ist die Digitalisierung, weil sie so viele bislang ungenutzte Synergien mit der Security bietet. Es ist doch Wahnsinn, dass wir in der industriellen Sicherheit seit Jahren ein neues Asset-Inventory-Tool nach dem anderen sehen, aber die vielen Überschneidungen mit Industrie-4.0-Entwicklungen nicht nutzen. Asset-Informationen sind doch kein Security-Thema, sie sind ein Digitalisierungsthema! Die Security ist aber einer der wichtigsten Antreiber dafür, dass man Assetinventare braucht.
Wenn man als Geschäftsführer eines KMU bisher wenig im Bereich OT-Security gemacht hat, wo würden Sie normalerweise anfangen?
Eine solide Security-Engineering-Methodik einführen und initial durchführen. Das ist Ihr wichtigstes Werkzeug, um alle weiteren Entscheidungen zu treffen.
Im Zuge dessen dokumentieren und lernen Sie nämlich viel über Ihre Systeme, und betriebliche Nadelöhre, Flaschenhälse und Balance-Akte, die Sie vielleicht noch gar nicht kannten – und Sie haben ein für alle Mal ein Modell Ihrer Systeme aus Security-Perspektive (das heißt oft: mit ungewohnt niedrigem Detailgrad), das Ihnen in Zukunft weiterhilft. Beispiel: Sie haben einen Security-Vorfall in der IT und sollen nun schnell die Kabel aus der Firewall ziehen, die IT und Automatisierung verbinden. Woher wissen Sie, was dann passiert? Das ist ein echter Fall einer unserer Kunden, und er konnte die Frage in einer halben Stunde beantworten – dank funktionsbasiertem Systemmodell.
Auch wenn die Risikoanalyse ein Kernbestandteil des Security-Engineerings ist, sage ich übrigens bewusst nicht „machen Sie eine Risikoanalyse“. Das wäre irreführend, denn Sie werden sehr viel mehr Zeit damit verbringen, Systeme zu verstehen und zu modellieren, als damit, Risiken zu bewerten.
Gibt es Security-Lösungen, die meistens unnötig oder ineffektiv sind, und die man deshalb eher an’s Ende der Roadmap schieben sollte?
Schauen Sie immer dann genau hin, wenn zusätzliche Systeme nur für Security eingeführt werden sollen. Diese „super-smarten Security-Lösungen“ sind nüchtern betrachtet wie jedes neue System erst einmal zusätzliche Komplexität und ein potentieller neuer Angriffsvektor. Das muss man gegen den Security-Nutzen gut abwägen. Es gibt viele wirksame Maßnahmen, ohne ein einziges Stück neue Hard- oder Software zu kaufen.
Ans Ende der Roadmap gehören Security-Monitoring, Anomalieerkennung und Threat Intelligence. Die Krux mit dem Anomalieerkennung ist, dass man wissen muss, was normal ist. Die Krux mit dem Security Monitoring ist, dass irgendjemand mit den vielen erzeugten Daten etwas anfangen können muss – er oder sie muss die Zeit und das Know How haben, und Sie müssen wissen, wie Sie mit kritischen Meldungen umgehen, sonst haben Sie nichts gewonnen. Threat Intelligence ist ähnlich gelagert: Es ist nützlich, zu wissen, welche Angreifer mit welchen Methoden gerade unterwegs sind (und welche davon vielleicht schon bei Ihnen im Netzwerk). Aber nur, wenn Sie aus dieser Information wirklich Nutzen ziehen können.
Fragen Sie sich bei all diesen Lösungen, die Ihnen zusätzliche Informationen liefern: Was fange ich mit den Informationen an? Welche Entscheidungen treffe ich anders, wenn ich diese Informationen habe? Wenn Sie das nicht sofort beantworten können, haben Sie wahrscheinlich noch ein Stück des Weges vor sich, bevor solche Lösungen Ihnen helfen.
Was sind Fehleinschätzungen oder Halbwahrheiten, die Sie auch von Experten immer wieder hören?
„Man muss ja immer zwischen Security und Komfort abwägen“. Das stimmt, wenn man Security auf lange Passwörter und unbenutzbare Verschlüsselungstools reduziert. Das sind aber in der industriellen Security eher Nebenschauplätze.
Gerade in der industriellen Sicherheit ist bei den wirksamsten Maßnahmen oft das Gegenteil richtig: Was der Security hilft, hilft auch einem effizienteren Betrieb. Industrielle Security hat viel mit Systeme verstehen, Überblick behalten, Konzentration auf das Wesentliche und Reduktion von Komplexität zu tun. Manchmal können Ingenieure sogar die Security als Sündenbock nutzen, um betriebliche Themen, die Ihnen schon lange schwer im Magen liegen, endlich anzugehen. Das kann das teure Upgrade auf eine neue Betriebssystemversion sein.
Wenn Sie eine E-Mail an alle CIOs dieser Welt schicken könnten, was wäre die Kernbotschaft?
Security funktioniert nicht als Stabsstelle (wo sie meistens angesiedelt ist). Steckt Eure Security-Beauftragten in die Linienorganisation, und beauftragt Menschen damit, die wissen, wie Euer Laden läuft.
Wenn Security funktionieren soll, muss sie von innen kommen – also von den Menschen, die mit und an den Systemen, die geschützt werden sollen, arbeiten. Security ist ohnehin schon ein Spielverderber-Thema, das geht nicht „von außen“ und es geht auch nicht ohne Budget und Entscheidungsgewalt, ohne Kenntnis der betrieblichen Abläufe – und, ganz wichtig: es geht nicht ohne Systemkenntnis.
Übrigens: Der Artikel spiegelt unseren aktuellen Wissensstand wider – aber auch wir lernen jeden Tag dazu. Fehlen aus Ihrer Sicht wesentliche Aspekte, oder haben Sie eine andere Perspektive auf das Thema? Gerne diskutieren wir mit Ihnen und weiteren Experten in Ihrem Hause die gegenwärtigen Entwicklungen vertiefend und freuen uns über Ihr Feedback sowie Anfragen zu einem Austausch.
Und zuletzt noch: Nennungen (oder die fehlende Nennung) von Anbietern stellt keine Empfehlung seitens CyberCompare dar. Empfehlungen sind immer abhängig von der kundenindividuellen Situation.
