Klaus Mochalski
Hallo und herzlich willkommen zu einer neuen Episode unseres Podcasts OT Security Made Simple. Mein Gast heute ist Sarah Fluchs. Sie ist CTO bei der admeritia GmbH. Sie beschäftigt sich schon seit vielen, vielen Jahren mit dem Thema OT und OT Security und ist dabei eine, was für Deutschland durchaus ungewöhnlich ist, auch international am sichtbarste Expertin. Und das ist sehr, sehr spannend. Sarah, stell dich doch mal ganz kurz selbst vor.
Sarah Fluchs
Eigentlich hast du das super gemacht. Also bei der admeritia bin ich CTO. CTO für ein Beratungsunternehmen, eine ein bisschen unübliche Position. Das liegt einfach daran, dass wir relativ viel Forschung machen und Methoden entwickeln. Und auch ein Stück Software entwickeln. Da sind wir aus Versehen hingekommen, da kommen wir vielleicht gleich nochmal drauf. Und dementsprechend decke ich da im Prinzip alles ab, was Methoden zum Thema Security nur für OT, also Automatisierungstechnik, angeht. Ursprünglich bin ich auch Automatisierungstechnikerin. Ich habe das mal studiert und bin dann aber ganz schnell abgebogen, mit einem Schlenker über das BSI, in Richtung Security.
Klaus Mochalski
Das heißt, das ist ein Thema, das dich tatsächlich schon sehr, sehr lange beschäftigt.
Sarah Fluchs
Zumindest definitiv seit Abschluss des Studiums. Ja, also die Automatisierung beschäftigt sich traditionell – das ist auch schon ein Teil des Problems – nicht so viel mit Security, sondern natürlich mit ihrer Technologie. Und die kommt ja auch erst langsam näher an die IT ran, dass man mehr IT-Komponenten verwendet usw. Und das lernt man auch erst so langsam. Und das Thema Security ist aber bei uns im Master höchstens etwas gewesen, wo man als Wahlfach mal reinschauen konnte und dann auch nicht wirklich spezifisch für Automatisierungssysteme. Das ist überhaupt ein Thema, das habe ich überhaupt nur gelernt, weil das BSI dazu Masterarbeiten ausgeschrieben hatte.
Klaus Mochalski
Ja, das ist spannend, dass das immer noch so ist. Es wird ja viel über diese Problematik gesprochen, aber eigentlich sollte man meinen, dass das mittlerweile in der Ausbildung angekommen ist. Gut, das ist jetzt bei dir auch schon ein paar Jahre her. Ich weiß nicht, wie es heute ist, aber das ist, glaube ich, ein anderes Thema.
Heute beschäftigen wir uns mit dem Thema "Security by Design". Und "Security by Design" ist in den letzten Monaten so ein bisschen zu einem Buzzword geworden – man könnte auch sagen verkommen. In der Vorbereitung haben wir darüber gesprochen, was man denn darüber noch sagen kann. Es wird gerade viel darüber gesprochen und wir wollen heute so ein bisschen mit den Mythen, die da zirkulieren, aufräumen.
Ich war vor einigen Wochen bei einer Veranstaltung in Israel, da ging es um "Security by Design", insbesondere für Kritische Infrastrukturen. Und da hatte ich tatsächlich in der Diskussionsrunde das Gefühl, dass man bei diesem Thema noch ziemlich am Anfang steht. Und dass vor allem viele die Hände heben vor der Herausforderung, "Security by Design" langfristig umzusetzen. Das liegt daran, dass man häufig die Lösung für das Problem bei den Herstellern von Komponenten, von Software, von Systemen sucht. Erzähl uns doch einmal aus deiner Sicht, wie der Stand bei "Security by Design" heute tatsächlich ist und was man dort als Betreiber einer Infrastruktur, man wird im Englischen auch Asset Owner sagen, beachten muss und wie man am besten vorgeht. Wie ist der Stand bei "Security by Design", wie du ihn heute bei euren Kunden beobachtest?
Sarah Fluchs
Also erstmal ist ja total interessant, dass das Thema "Security by Design" eigentlich noch immer nicht so richtig etabliert ist, weil es ja keine neue Erfindung ist. Auch wenn es in letzter Zeit so ein bisschen mehr Schwung bekommen hat. Sondern das gibt es, bezogen auf Softwaresysteme, schon seit den 1980er und 1990er Jahren, dass man sagt “Hey, es wäre ja vielleicht gut, wir würden das direkt mit berücksichtigen, wenn wir Systeme entwickeln und nicht erst irgendwann später. Lass uns doch mal überlegen, wie man das macht”.
Klaus Mochalski
Die Idee klingt ja sehr gut, und es ist intuitiv einsichtig, dass man eben sagt, wir machen uns Gedanken zu Security. Nicht wenn das Produkt auf der Straße ist, sondern ganz am Anfang, wenn wir es projektieren und bauen. Das heißt, die Idee gibt es natürlich schon viele, viele Jahre, aber scheinbar hat es das noch nicht so richtig in die Praxis geschafft.
Sarah Fluchs
Es ist komplett einsichtig und das ist auch der Grund, glaube ich, warum das als Buzzword so erfolgreich ist. Weil es natürlich etwas ist, wo auch jeder gerne aufspringt und sagt “Na klar, macht das Sinn”. Also ich glaube, das muss man wirklich, wirklich niemandem erklären, warum "Security by Design" eine gute Idee ist oder zumindest wäre.
Es gibt ja auch im Engineering – auch in anderen Bereichen – diese auch schon viel belegte These. Obwohl es ist keine These mehr ist. Es ist wirklich belegt. Dass es, wenn man Fehler früh im Design findet, exponentiell günstiger ist, sie zu beheben, als wenn man sie später findet. Da gibt es so schöne Kurven für, und das gilt natürlich für Security ganz genauso. Und du hast gerade gesagt: Was müssen denn Betreiber da beachten? Und ich glaube, da bekommen die Zuhörer wahrscheinlich schon den ersten Knoten im Kopf, weil "Security by Design" ist ja üblicherweise ein Thema, was sehr stark mit Herstellern assoziiert wird. Was ja auch Sinn macht, wenn man sagt “Okay, Security soll während der Entwicklung einer Komponente berücksichtigt werden”. Da spricht man natürlich mit den Leuten, die die Komponente entwickeln. Die müssen da irgendwas tun. Das macht auch Sinn.
Jetzt sind wir ja hier in einem sehr speziellen Bereich – die Security für Automatisierungssysteme und Automatisierungstechnik. Und da ist es so, dass es für das System verschiedene Rollen im Markt gibt. Es gibt Hersteller von Automatisierungssystemen. Es gibt die sogenannten Integratoren, die das Ganze zu einem Gesamtsystem zusammenbauen und wirklich dafür da sind, eine Anlage zu automatisieren. Dann gibt es die Betreiber dieser Anlage. Also, ich habe ein Klärwerk, ich bin ein Betreiber so einer Anlage, und der hat dann in der Regel einen Dienstleister oder auch zwei Dienstleister. Dieser [Betreiber] sagt: “Okay, ich hätte gerne ein Leitsystem von Siemens”. Irgendjemand muss aus diesem Leitsystem von Siemens und den Steuerungen von Siemens und den Sensoren von Wago – oder was auch immer – ein System machen, das tatsächlich diesen Prozess der Wasseraufbereitung automatisiert.
So, das heißt, man hat immer diese drei Rollen. Das bedeutet aber, dass, wenn man sagt – was in der Softwareentwicklung relativ einfach umzusetzen ist – “Ja, Mensch, "Security by Design" ist der Job der Softwarehersteller oder der Komponentenhersteller”, dann muss das halt Microsoft machen oder wer auch immer diese Software herstellt. Bei Open Source wird es schwierig, aber das ist ein anderes Thema. In der Automatisierungstechnik ist das aber eben nicht so einfach. Man kann natürlich sagen – analog wie bei der Softwareentwicklung – “Siemens, du stellst das Leitsystem her. Wago, du stellst den Sensor her. Ihr müsst jetzt "Security by Design" berücksichtigen”. Da ist das analog, da redet man nur über Hersteller. Aber das ist halt bei weitem noch nicht alles, was Design für so ein Automatisierungssystem ist. Es wird erst ein zu einem Automatisierungssystem, wenn es auch zu einem Gesamtsystem integriert wird. Und spätestens da hört es halt bei den Herstellern auf.
Die übernehmen manchmal diese Rolle des Integrators noch mit. Trotzdem ist es noch eine weitere Rolle. Und ganz oft ist es auch so – kommt auch auf die Organisation an – dass die Betreiber zum Beispiel des Klärwerk oder der Hersteller von chemischen Produkten oder, oder oder auch was damit zu tun haben, auch Engineering-Abteilungen haben, die dafür sorgen, dass das Gesamtsystem hinterher funktioniert. Und da ist natürlich auch ein Stück Design und da muss Security auch rein. Deswegen ist es tatsächlich so, dass in der Automatisierungstechnik es nicht so einfach ist zu sagen, der Hersteller macht es, und der Rest ist da fein raus.
Klaus Mochalski
Das heißt, wenn ich dich richtig verstehe… Also erstmal gibt es die drei Rollen, um das zu wiederholen. Das sind die Hersteller, das sind die Integratoren, und das sind die Anwender. Und du sagst, es sind also nicht nur die Hersteller, wie man das bei dem Thema vermuten würde, sondern die Integratoren spielen eine ganz wichtige Rolle. Welche Rolle spielt denn jetzt der Anwender? Spielt er auch eine Rolle? Ist die Verantwortung gleich verteilt, oder sticht da so eine Verantwortung heraus in einem bestimmten Bereich?
Sarah Fluchs
Das Problem ist, dass das total unterschiedlich ist. Also genau diese Frage haben wir uns gestellt. Wir haben vor drei Jahren angefangen mit einem großen Forschungsprojekt zum Thema "Security by Design". Wir haben gesagt: “Mensch wäre doch gut – man will ja Security im Engineering Prozess unterbringen –, wenn man das auch für Automatisierungssysteme macht”. Und dann überlegt man sich so reißbrettartig: Was macht man denn da? Man sagt: “Okay, ist ja eigentlich auch relativ straight forward [geradlinig, Anm. d. Red.]. Wir machen das so, wir schauen uns mal an, wie der Engineering Prozess abläuft und dann gucken wir, wie wir Security da rein kriegen”. So hatten wir einen Plan.
Dann haben wir angefangen zu schauen, wie denn der Engineering Prozess abläuft. Und haben festgestellt, dass das erstens sehr schwer verallgemeinerbar ist, weil auch die Studien darüber komplett unterschiedlich sind, allein schon für die unterschiedlichen geografischen Gegebenheiten. In Europa läuft der Engineering Prozess komplett anders, als in den USA oder in Südamerika. Das hängt auch damit zusammen, wie viel neue Anlagen eigentlich noch gebaut werden oder ob es eine Tendenz gibt dazu, ob Anlagen komplett neu gebaut werden oder bestehende eher erweitert werden. Europa hat ein Platzproblem, neue Anlagen gibt es da nicht mehr so oft. In anderen Ländern sieht das anders aus. Da gibt es andere Standards, die die erfüllen müssen, die ganz große Implikationen haben und und und.
Aber das Wichtige war, dass wir am Ende gesagt haben, “Mensch auch, wie diese Verantwortung verteilt ist, dass ist echt total individuell und hängt auch total von der Unternehmenskultur ab”. Also wir haben zum Beispiel einen Anwendungsfall in unserem Forschungsprojekt, bei denen ist auch wirklich Kultur, dass sie ziemlich vieles selbst machen, ziemlich viel selbst engineeren. Dementsprechend machen die auch ziemlich viel dieses Integrator-Jobs. Also die Fragen “Wie kriege ich das System zu einem Gesamtsystem? Wie programmiere ich meine Steuerung usw?” machen die tatsächlich selbst. Gleichzeitig gibt es aber auch ganz viele Anwender, also Betreiber der Organisationen, die das nicht selbst machen, komplett abhängig vom Dienstleister sind. Deswegen macht es da mehr Sinn in diesen Rollen zu denken und weniger in Organisationen, die da ganz fest dazugehören. Am Ende ist es wichtig, wer zum Design beiträgt und das kann über diese Rollen total verteilt sein.
Klaus Mochalski
Gibt es da oder oder fehlt es hier an Standards an Standardisierungs-Frameworks? Wenn ich höre Unternehmenskultur, ist das ein Aspekt, der sehr schwer messbar ist. Und da gibt es ja ganz viele unterschiedliche Ausprägungen. Ich brauche aber trotzdem eine gewisse Basis, von der ich starte, um dann auch einen messbaren Fortschritt zu erreichen. Was ich ja tun möchte, wenn ich mein System sicher designe und implementiere.
Sarah Fluchs
Wir tauchen jetzt in ein sehr großes Forschungsfeld ein, eines das mit Security gar nicht mehr so viel zu tun hat, wo wir auch irgendwann gesagt haben "Not our Business". Das ist übrigens auch eine ganz wichtige Erkenntnis auf dem Weg gewesen, dass Security sich nicht anmaßen kann, diese existierenden, schon lange optimierten Engineering-Prozesse zu verändern. Wir müssen mit dem arbeiten, was wir haben.
Also aus der Security heraus werden wir nicht sagen, “Engineered uns mal die Anlage anders”. Da zeigen die uns vollkommen zu Recht den Vogel. Weil da wird seit Jahren, seit Jahrzehnten daran gearbeitet. Wie macht man das?
Und es gibt natürlich solche Standards. In Deutschland gibt es zum Beispiel für die Prozessindustrie den Namur-Standard NA 35, der relativ klar beschreibt, wie so ein Engineering eigentlich abläuft. Aber wenn man mit den Leuten spricht, die das entwickelt haben, dann sagen sie "Na ja, was man da in die Standards schreiben kann, ist weniger das, was wir umsetzen". Wahrscheinlich gibt es keine Organisation auf der Welt, die das genauso befolgt. Es ist mehr das Destillat aus dem, was alle machen. Und häufig haben aber die Unternehmen selbst natürlich ihre eigenen Standards, also die sie selber auch angepasst haben an das, was sie machen und durchführen. Und das sind ja durchaus auch große Unternehmen, von denen man da teilweise spricht. Also wenn man jetzt von, keine Ahnung, Shell spricht oder BASF spricht oder sonst was, die sind ja global und die haben natürlich Standards, wie sie sowas machen. Das ist aus ganz vielen Richtungen getrieben. Also da würde ich mir weder anmaßen, eine Meinung zu haben, ob da noch Standards fehlen und auch nicht sagen, dass es keine gibt. Tatsächlich sollte die Security sich da raushalten. Die muss mit dem Material arbeiten, das sie hat. Niemand sollte seinen Engineering-Prozess nur wegen Security umbauen.
Klaus Mochalski
Das ist schon mal eine sehr gute Aussage, dass wir – und mit wir meine ich uns Security-Dienstleister – uns den Gegebenheiten anpassen müssen und dass die Möglichkeiten, bestimmte Dinge zu ändern, dort sehr limitiert sind. Dass wir eben nicht den Ingenieuren sagen können, “Ihr müsst die Anlage jetzt anders bauen, weil das so nicht sicher ist”.
Sarah Fluchs
Das wäre eine komplette Anmaßung. Also ganz ehrlich, das wäre, als würde der Schwanz mit dem Hund wedeln. Also Security hat ja gar keine Daseinsberechtigung, wenn es diese Anlage nicht gibt, die läuft. Also Security ist in dem Sinne, ich sage mal gerne provokativ, so eine Hilfswissenschaft. Ja, wir sind dafür da, dass es sicher läuft und resilient läuft usw. Aber wenn es die Anlage nicht gibt, dann gibt es uns auch nicht mehr.
Klaus Mochalski
Na klar. Und bei den ganz großen Unternehmen kann ich mir auch sehr gut vorstellen, wie das funktioniert. Weil da gibt es natürlich sehr viel, was schon existiert, auch durchaus unternehmenseigene Standards, wie man bestimmte Dinge tut. Und da ist dann die Security-Implementierung letzten Endes eine Erweiterung dieses durchaus auch stark intern geprägten Rahmens, der dort gesteckt ist. Aber wie mache ich das jetzt aus Sicht eines kleineren Unternehmens, was eine Anlage betreibt und was sich mit dem Thema bisher noch wenig beschäftigt hat. Das auch keine große Abteilung dazu hat und sich vielleicht auch nicht die große Beratungs-Unterstützung leisten kann. Wenn ich jetzt als kleines bis mittelgroßes Unternehmen für meine durchaus kritischen Anlagen mit dem Thema "Security by Design" starten möchte. Was sind da deine konkreten Empfehlungen an diese Unternehmen? Was sollte man zuerst tun? Was sind die Prioritäten und wie erreicht man den schnellsten messbaren Mehrwert?
Sarah Fluchs
Also ich glaube, zuallererst muss man verstehen, dass, gerade wenn man selber nicht viel Engineering macht als Anwender oder als Besitzer einer Anlage, dann natürlich "Security by Design" primär ein Kommunikationsproblem ist. Denn da mache ich ja selber nicht viel Engineering. Da kann ich aber auch beim Engineering nicht so viel verändern. Aber ich muss eben sehr genau den Dienstleistern, die ich habe – das Engineering macht wahrscheinlich dann ein Integrator oder eben ein Hersteller oder einer in beiden Rollen – sehr klar verklickern, was ich brauche. Und das ist dann an der Stelle die Verantwortung des Asset Owners, also des Betreibers.
Wenn ich wirklich kein Engineering mache, dann kann ich natürlich Security auch nicht in mein Engineering integrieren. [Und da gibt es einen Unterschied zwischen Nutzer und Betreiber.]. Wenn ich eine reine Software habe, dann bin ich Nutzer eines Systems, da mache ich nicht mehr viel damit. Aber so ein Betreiber interagiert noch auf einer ganz anderen Basis mit so einem System und macht auch immer noch ein paar Veränderungen. Und der hat da mehr Verantwortung und hat vor allem auch häufig eine Betreiberverantwortung, was die Security angeht.
Klaus Mochalski
Das ist sehr spannend. Das heißt, da bin ich dann als Betreiber doch in der Verantwortung und kann mich nicht komplett auf meine Hersteller und Systemintegratoren festlegen und den sagen: “Euer Auftrag ist, mir ein System, was Secure by Design ist, zu liefern”. Sondern ich muss denen schon mehr mitgeben, was ich konkret brauche.
Sarah Fluchs
Also sagen wir mal so, es ist ja erstmal keine Überraschung, dass die Betreiber eine Betreiberverantwortung haben. Deswegen haben wir ja bergeweise Regulierung für Kritische Infrastrukturen usw., weil man diese Verantwortung ja natürlich auch irgendwo anders hinlegen kann.
Klaus Mochalski
Natürlich also Verantwortung für den sicheren Betrieb der Anlagen. Das ist natürlich unstrittig, aber auch Verantwortung für die erfolgreiche Umsetzung eines "Security by Design" Konzepts. Denn da hätte man ja durchaus sagen können, dass die [Betreiber] damit relativ wenig zu tun haben. Aber das scheint ja nicht so zu sein.
Sarah Fluchs
Sagen wir so, das kann man machen, aus Betreibersicht zu sagen "Not my Job, "Security by Design"". Erfahrungsgemäß läuft das dann so, dass der Betreiber sagt "Not my Job. Macht ihr "Security by Design", bietet mir etwas an, was Secure by Design ist”. Da kommt dann der Hersteller wieder mit einem aus seiner Sicht erst mal “Secure by Design”-System. Er muss ja interpretieren, was der Anwender da so haben wollte und das findet der Anwender auch alles toll. Und dann hängt der Hersteller ein Preisschild dran. Und an diesem Punkt passiert dann das, was mit der Security häufig passiert: “Hm, ja okay, also wenn das so ist, dann würde vielleicht bisschen weniger Security auch reichen”. Und da fängt dann so ein “türkischer Basar” an, man streicht das zusammen oder nimmt dann doch das unsichere System.
Also es gibt tatsächlich viele Hersteller, die genau aus dem Grund für alle Komponenten zwei Versionen haben. “Ich habe meine Engineering Station in sicher und in nicht sicher. Was wollen Sie? Die eine kann das das das. Die andere kann das das das. Hier sind die Preisschilder.” Und jetzt kann man gut raten, was die meisten Betreiber eben nehmen. Aber gerade wenn man das Thema Security relativ am Ende mit einwirft, dann stehen viele andere Dinge fest. Dann muss man eben mit dem Budget arbeiten, das man hat. Und dann ist dafür halt kein Platz mehr.
Klaus Mochalski
Und wie komme ich als Betreiber jetzt aus dem Dilemma raus. Das ist ja das Spannende.
Sarah Fluchs
Genau da haben die Betreiber natürlich schon eine Verantwortung. Das gibt es ja Schwarz auf Weiß. Entweder ich kümmere mich gar nicht und mache es einfach. Da kommt dann irgendwas raus. Oder ich kann natürlich schon vorher sagen und überlegen – wie mit allen Features auf dieser Welt –, was ich brauche. Und das ist in der Security nicht so einfach. Also es scheiden sich auch die Geister an so einem Konzept wie Securitylevel usw., wo man sagen kann, “Okay, für Security Level vier hast du diese Features, für drei hast du diese Features, für zwei hast du diese Features”. Und dann ist die Wunschvorstellung immer, dass so ein Betreiber hingehen und sagen kann: “Mach mir doch Security Level X und dann bin ich glücklich”.
Aber die große Frage ist ja, wie komme ich denn als Betreiber überhaupt zu der Erkenntnis, was mir wichtig ist? Also am Ende ist es ja nicht wichtig, mein Produkt mit allen Security Features zuzuwerfen, die ich mir ausdenken könnte. Sondern es ist wichtig, dass ich mir überlege, was denn wirklich für den Betrieb meiner Anlage relevant ist. Und das kann natürlich der Hersteller nur bedingt wissen, weil er nur bedingt wissen kann, was eigentlich die Prioritäten sind von so einem Betreiber. Ist das jetzt für den [Betreiber] schlimm, wenn die Anlage ausfällt oder nicht? Ist das für den jetzt schlimm, wenn die X Minuten ausfällt? Ist dieser Sensor wichtig oder der? Das kann [der Hersteller] ja nicht alles wissen. Oft weiß man Teile davon aus der funktionalen Sicherheit, aber die hat dann wieder eine andere Schwerpunktsetzung.
Das heißt, der Betreiber hat schon die Verantwortung zu kommunizieren, was er eigentlich will. Und dieses Kommunizieren, was ich eigentlich will, geht halt immer damit einher, sich [vorher] ein Stück weit auch zu überlegen, was ich will. Und dann sind wir schon beim Thema, wo ich anfange mit "Security by Design".
Klaus Mochalski
Das heißt, der Betreiber kommt eigentlich nicht drumherum, den Experten für den Betrieb der Anlage, den er höchstwahrscheinlich hat, zu befragen und den Experten für die Sicherheit solcher Anlagen, den er hat oder vielleicht auch nicht hat – häufiger nicht hat. Und die müssen sich zusammensetzen im Vorfeld und müssen sich überlegen, was denn meine Optimierungsziele sind? Welches sind die kritischen Elemente meiner Anlage und wie viel Sicherheit und welche Art von Sicherheit brauche ich? Und erst wenn ich diese Informationen für meine spezifische Anlage zusammengetragen habe – und dazu brauche ich eben sowohl die technische als auch die fachliche Cyber Security Expertise –, erst dann kann ich wirklich an einen Systemintegrator oder Hersteller herantreten und sagen "Diese Anlage hätte ich gern von euch". Ist das richtig?
Sarah Fluchs
Zwei Punkte, die ich gerne in ein anderes Licht rücken würde. Das eine ist, was du gerade gesagt hast. Dass der Systemexperte und der Security-Experte sich zusammensetzen müssen. Erfahrungsgemäß funktioniert das nicht so gut. Erfahrungsgemäß hat man so Lager. Einmal denjenigen, der will, dass das alles funktioniert. Und dann den Spielverderber, der die Security will, der aber vom System keine Ahnung hat und sich dementsprechend das Standing im Unternehmen zu diesem Thema erst erarbeiten muss, sage ich mal vorsichtig.
Wir haben in den letzten drei Jahren viele Testprojekte gemacht zum Thema "Security by Design" bei Herstellern, aber auch bei Betreibern. Erfahrungsgemäß funktioniert es viel besser, wenn man sich diesen Systemexperten nimmt, diesem diese Entscheidungen vorsetzt und ihm bestimmte Fragen stellt. So dass die [Systemexperten] das Thema damit übernehmen. Also es ist organisatorisch nicht immer einfach, aber erfahrungsgemäß funktioniert es besser zu sagen: “Wir nehmen Systemexperten und leiten diese an, dass sie bestimmte Security-Entscheidungen mitentscheiden können”. Anstatt zu sagen, dass diese Entscheidung der Security-Experte treffen muss. Da wäre der Systemexperte raus, denn das allerwichtigste Wissen, was ein Betreiber da reinstecken kann, ist das Wissen über seine Systeme. Und wenn das entkoppelt ist von den Security-Entscheidungen, dann trifft man Murks-Entscheidungen. Wenn sie sich zusammensetzen, kann das funktionieren. Und es muss natürlich irgendwo die Security-Expertise herkommen, wie man das organisatorisch löst. Da gibt es viele Wege nach Rom, aber der Systemexperte sollte das mit entscheiden.
Klaus Mochalski
Das ist natürlich ein sehr spannendes Thema, über das ,glaube ich, auch schon viel diskutiert und gestritten wurde. Ist denn das überhaupt lösbar? Es gibt ja auch durchaus Aussagen, die da draußen kursieren, dass ein Systemexperte niemals die jahrelange Erfahrung und die Einstellung in Hinblick auf Cyber Security aufholen kann und dass ich deswegen immer diesen Cyber-Security-Experten brauche. Aber dass ich dann natürlich diesen Konflikt habe, den du beschreibst. Das heißt, hier ist, glaube ich, nach wie vor der Königsweg nicht gefunden. Den wird es vermutlich nie geben. Das ist auch mein Gefühl so in der Erfahrung mit unseren Kunden. Jeder Kunde verhält sich anders aufgrund der agierenden Personen. Also welche Expertise habe ich in welcher Person? Wie stark oder wenig stark kennt sie sich mit dem Thema Security aus? Wie offen sind die dafür? Häufig gibt es ja eine gewisse Abwehrhaltung. Das ist, glaube ich, ein Riesenthema, was auch einen kompletten Podcast füllen könnte.
Sarah Fluchs
Ein kurzer Punkt dazu. Andersrum wird ein Schuh draus. Du kannst die Security-Entscheidung in den Raum werfen und den Security-Experten rausnehmen, wenn du die Entscheidung einmal gesagt hast: “Das hier muss entschieden werden: Wollen wir X oder Y?” Du kannst dann den Security-Experten rausnehmen, und dann wird auch eine halbwegs irgendwie sinnvolle Entscheidung herauskommen. Wenn du aber den Systemexperten rausnimmt, hast du nur noch Murks. Die Security-Leute können es halt nicht entscheiden, ohne diese System-Expertise. Die muss da irgendwie drin sein, und die [System-Expertise] ist eben sehr spezifisch für ein bestimmtes Unternehmen. Die Security-Expertise oft nicht so sehr.
Klaus Mochalski
Klar, die Anlage läuft nicht ohne den Anlagenexperten, aber sie läuft natürlich ohne den Security-Experten. Die Frage ist nur, wie lange und wie [hoch] ist das Betriebsrisiko.
Sarah Fluchs
Ich habe nicht gesagt, dass die Anlage läuft. Ich habe gesagt, die Security-Entscheidung kann getroffen werden. Also die Security-Entscheidung, wenn man sie einmal getroffen hat. Und das ist das große Wenn dahinter, ich weiß ja. Wenn man einmal offen gelegt hat, das müssen wir entscheiden, das sind die Parameter. Das ist aber Wissen, das von der Anlage selbst relativ unabhängig ist. Deswegen kann man das eher als Hilfestellung mit reingeben in so eine Entscheidung, als das Systemwissen für ein einzelnes Unternehmen. Da kann der Systemexperte so eine Entscheidung mit ein bisschen Anleitung treffen. Der Security-Experte kann sie aber nicht treffen, ohne dieses Systemwissen. Und dieses Systemwissen kann man schlecht anlagenübergreifend verallgemeinern. Das geht nicht.
Klaus Mochalski
Ja, das ergibt Sinn. Ich glaube, das Fazit aus dem, was wir bisher diskutiert haben, könnte wirklich sein – und das ist so ein bisschen auch ein Twist, den du dort dem Thema "Security by Design" gibst, der durchaus anders ist, als man das üblicherweise hört. Die Verantwortung kann man eben nicht allein den Herstellern und Systemintegratoren geben, sondern der Betreiber der Anlage, der Asset Owner, ist hier in einer ganz wichtigen Verantwortungsrolle. Und nur wenn aus dieser Richtung substanzielle Vorgaben kommen, kann das Gesamtprojekt erfolgreich sein. Kann man das so als Zusammenfassung formulieren, oder was würdest du dem noch hinzufügen?
Sarah Fluchs
Also zwei kleine Einschränkung. Erstens: Natürlich sprechen wir über Automatisierungssysteme, wo es eben sehr stark dieses verteilte Engineering über verschiedene Organisationen gibt. Das gilt natürlich nicht für Commodity-IT-Produkte, da kann die ganze Usergemeinde befragt werden, was sie denn gerne hätte. Also, den basisdemokratischen Ansatz will ich da gar nicht reinbringen.
Und das zweite ist: Es gibt natürlich bestimmte Praktiken und Grundlagen, die Sinn machen, als Hersteller unabhängig davon zu beachten. Es ist natürlich trotzdem wünschenswert, dass man – das ist immer das, was "Security by Design" fordert, ist aber eine sehr schwierige Forderung – so wenig Schwachstellen wie möglich im Endprodukt hat. So, das lässt sich immer leicht fordern, genauso wie "Security by Design" an sich. Und das unterschreibt jeder. Ist eine super Sache. Aber wie komme ich denn dahin? Also, wie kriege ich denn das hin? Und das ist natürlich was, da kann der Betreiber relativ wenig zu beitragen. Der kann nur sagen, an welcher Stelle Schwachstellen für ihn besonders schlimm sind und wo es besonders wichtig ist. Oder was für ihn überhaupt eine Schwachstelle ist, weil da sind wir auch wieder bei einem anderen Thema. Also das ganze Thema “Insecure by Design”-Features oder auch Features, die halt Anlagenbetreiber oder gerade in der OT einfach gebraucht werden, die vielleicht in anderen Bereichen potenziell als Schwachstelle definiert werden können.
Ein gutes Beispiel ist immer die Frage: “Kann ich eigentlich meine SPS im laufenden Betrieb noch updaten?” Aus Security-Sicht schlage ich natürlich die Hände über Kopf zusammen und sage "Um Himmels willen, nein! Das öffnet doch Tür und Tor für Angreifer. Scheunentore!” Aber das ist fast in jedem Betrieb möglich, weil der Betreiber das braucht. Der kann nämlich nicht jedes Mal die Anlage herunterfahren, weil er die Logik ändern will, weil die ändert man dann doch erstaunlich häufig. So, und das sind so Klassiker, wo man eben austarieren muss: Wo man zwar mal sagen kann, “Ja, keine Schwachstellen mehr”. Das klingt wie ein tolles Ziel. Aber was heißt das eigentlich? Was ist eigentlich die Schwachstelle? Das kann der Hersteller nicht komplett alleine entscheiden. Da braucht es einen Dialog.
Klaus Mochalski
Das heißt, es ist quasi – wie so oft –, dass es hier um ein Austarieren der Verantwortung geht zwischen Betreiber, zwischen Hersteller, zwischen Integrator. Da können die Rollen auch durchaus verschmelzen oder sich überlappen. Aber dass die Verantwortung auf alle diese Parteien verteilt wird. Und dass ein Projekt nur dann erfolgreich werden kann, wenn die Probleme in diesem Spannungsverhältnis dieser Parteien diskutiert und durch Kommunikation erst mal definiert und dann auch in der Umsetzung gelöst werden. Das heißt, keine der Parteien alleine kann das Problem lösen.
Ein Hersteller kann nicht das perfekte, sichere Produkt bauen, und dann ist das für den Betreiber gelöst. Sondern der Betreiber kommt eben nie ganz aus der Verantwortung raus. Und das Wichtige dabei ist immer die Kommunikation zwischen den Parteien, um eben aus Betreibersicht die Anforderungen genau zu definieren. Der Hersteller muss dann ein Produkt haben, was diese Anforderungen umsetzen kann und der Integrator muss natürlich beides zusammenbringen und dann daraus eine Anlage bauen, die diesen Anforderungen gerecht wird.
Sarah Fluchs
Ich glaube, wir müssen das Blame Game da irgendwie herunterfahren. Im Moment ist es so, dass die Betreiber sagen: “Hersteller, stell mir halt mal was hin, was sicher ist!”, und die Hersteller sagen “Zahl halt dafür.” oder “Dann sag mir doch, was du willst”. Und es ist, glaube ich, gar nicht wichtig, dass wir bis ins Letzte austarieren, wer welche Verantwortung hat. Es ist einfach wichtig, dass wir anfangen zu akzeptieren, dass eben jeder ein Stückchen Verantwortung hat und dass es Sinn macht, transparent darüber zu reden, und zwar früh genug. "Security by Design" bedeutet vor allem auch “Communication by Design”. Also früh genug anfangen, über bestimmte Dinge zu reden, ein gemeinsames Bild davon zu bekommen, was man eigentlich will, und dass eben auch beide Seiten was dazu beitragen können.
Klaus Mochalski
Das heißt Kooperation und Transparenz, anstelle Kommunikationsbarrieren und am Ende Finger zeigen, wer dann schuld ist, wenn es eben doch nicht erfolgreich war.
Sarah Fluchs
Ja, vor allem nicht so ein Hochrüstung-Krieg. Ich hätte gerne Security Level vier, und da stecken diese X Anforderungen drin. Und eigentlich weiß jeder, dass das für bestimmte Produkte gar nicht so geht. Dann kommt der Hersteller, und der will natürlich irgendwie mauern und erklären, dass er das alles irgendwie kann. Und wenn nicht, dann ist das auch nicht transparent. Dann kommt man mit dem, was man dann irgendwie versucht, da hinzukriegen.
Und dann sagt der Betreiber wieder, “Ja, aber du kannst das nicht und das nicht. Und das ist zu teuer”. Das hilft am Ende nicht. Sondern wenn man gar nicht erst anfängt mit: “Ich hätte gerne Security Level X. Der Punkt steht in der IEC62443. Macht das so!” Sondern wenn man schon eine Stufe vorher anfängt mit “Was will ich eigentlich erreichen?”
Dann hat nämlich auch der Hersteller, der so eine Anforderung kriegt, eine Chance zu sagen: "Pass auf, ich kenne ja meine Systeme. Wenn du das erreichen möchtest, ist diese Anforderung gar nicht so sinnvoll, sondern lass uns mal drüber sprechen, ob wir es anders machen wollen”. Und ja, das ist mühsamer, als einfach eine Feature-Liste herüberzuschieben. Aber am Ende ist das Ergebnis dann günstiger, weil man nicht ständig irgendwelche Features implementiert, die vielleicht niemand haben wollte und ganz viel Geld kosten.
Klaus Mochalski
Ja, das ist ein schönes Schlusswort. Wir plädieren für mehr Kooperation. Du plädierst für mehr Kooperation zwischen den beteiligten Parteien und weniger aggressive Sprache und Wettrüsten. Auch aus unserer Erfahrung fühlt sich insbesondere eine Ausschreibung häufig so an, als ob sich die Parteien gegenüberstehen und der jeweils andere eher der Feind ist. Aber wir müssen eigentlich von Anfang an Verbündete sein, und die Kooperation muss von Anfang an im Vordergrund stehen. Sonst ist es am Ende viel schwieriger, dass ein erfolgreiches Projekt daraus wird.
Sarah Fluchs
Erwartungen herunterschrauben und Transparenz hochschrauben. Das wäre schön, auch wenn man weiß, dass es bei Security immer so extra schwierig ist mit der Transparenz.
Klaus Mochalski
Sehr schön, Dann herzlichen Dank dafür. Es hat mir Spaß gemacht. Ich glaube, wir können das Thema noch viel weiter vertiefen. Es hat mich gefreut, dass du heute hier in der Show warst.
Sarah Fluchs
Danke dir. Es hat Spaß gemacht.
