Cybersecurity 
in the 
Power Grid – 
360°-Blick| Teil 6

Willkommen zur 6. Folge unserer Energy Talks-Miniserie Cybersecurity in the Power Grid, in der wir einen 360-Grad-Blick darauf werfen, wie Stromnetze ihre Infrastrukturen am besten vor Cyberangriffen schützen können.

In dieser Folge diskutiert Andreas Klien, OMICRON's Business Area Manager für Power Grid Cybersecurity, mit seinem Gast Ron Brash, einem renommierten Forschungsexperten für Schwachstellen in der Luftfahrtindustrie und Vizepräsident für technische Forschung und Integration bei aDolus in British Columbia, Kanada, über die Unterschiede und Gemeinsamkeiten beim Einsatz von OT-Technologie in der Luftfahrt- und der Stromversorgungsbranche.

Andreas und Ron tauschen sich darüber aus, was in ihrer langjährigen Erfahrung in der Luftfahrt- und Stromversorgungsbranche schon alles schief gelaufen ist. Sie beleuchten die Faktoren, die zu Verstößen gegen die Cybersicherheit aus der OT- und IT-Perspektive geführt oder diese beinahe verursacht haben, und tauschen nützliche Strategien aus, die in ihrer Branche zur Risikominderung beitragen.

Episode jetzt anhören!

Scott Williams, Moderator Willkommen zu Energy Talks, einer regelmäßigen Podcast-Reihe mit Expertengesprächen über Themen im Zusammenhang mit der Prüfung von Stromversorgungssystemen, Datenmanagement und Cybersicherheit in der Stromwirtschaft.

Hallo zusammen! Mein Name ist Scott Williams vom Podcast-Team bei OMICRON. Dies ist die sechste Folge unserer speziellen Energy Talks-Miniserie mit dem Titel "Cybersicherheit und das Stromnetz", in der wir Ihnen einen Rundumblick geben, wie Stromnetze am besten vor Cyberangriffen geschützt werden können. In dieser Folge ist der OMICRON-Cybersicherheitsexperte Andreas Klien unser Gesprächsleiter, und ein besonderer Gast wird mit ihm über die Chancen und Risiken der operativen Technologie (OT) im Energie- und Luftfahrtsektor sprechen. Herzlich willkommen, Andreas, und vielen Dank, dass du diese Folge moderierst.

Andreas Klien, Gesprächsleiter Danke Scott! Hallo und herzlich willkommen zur sechsten Folge unserer Cybersecurity-Miniserie "Energy Talks". Mein Name ist Andreas Klien und ich bin Ihr Gesprächsleiter für diese Folge, in der es um Cybersicherheit in der Luftfahrt und den Zusammenhang mit der Cybersicherheit im Stromnetz geht und was wir voneinander lernen können. Ich beschäftige mich seit fast 19 Jahren mit der Kommunikation in Stromnetzen. In 14 dieser Jahre habe ich mich auf die Cybersicherheit von Stromnetzen konzentriert und bin für die Leitung des Geschäftsbereichs Power Utility Communications bei OMICRON verantwortlich. In dieser Folge spreche ich mit dem renommierten Schwachstellenforscher und Firmware-Dissektor, insbesondere für OT- und kritische Infrastruktur-Firmware und Geräte-Firmware, sowie mit dem Vizepräsidenten für technische Forschung und Integration des Unternehmens aDolus und 40 under 40 Engineering Leaders Award-Gewinner Ron Brash.

Ron Brash, Gastexperte Danke, Andreas, dass ich dabei sein darf. Es ist großartig, in solch geschätzter Gesellschaft zu sein. Das sind wirklich nette Worte, aber ich denke, der wahre pragmatische Ingenieur bin nicht ich. Es bist du, Andreas. Zumindest in all unseren Gesprächen.

Andreas Klien Ich danke dir vielmals. Es ist mir eine Ehre, dich hier zu haben. Ich habe erst kürzlich erfahren, dass du die Auszeichnung "40 under 40 Engineering Leaders" erhalten hast. Das ist sehr beeindruckend. Wann hast du diese Auszeichnung erhalten?

Ron Brash Ich glaube, es geschah während der dunklen Jahre von Covid. Ich habe nie ganz herausgefunden, wer mich nominiert hat. Aber ehrlich gesagt, ist es eine ziemlich ernüchternde Auszeichnung. Vor allem, weil ich kein Ingenieur von Beruf bin und das in meinem Land nicht nutzen kann. Aber ich glaube, es geht eher darum, dass man in der Lage ist, schwierige Fragen zu stellen und die Sache direkt anzugehen. Und in manchen Branchen ist das irgendwie komisch. Und warum? Es ist eine Auszeichnung, die nicht gerade willkommen ist, aber wir sind heute hier, um harte Fragen über Energie, Öl und Gas und Luftfahrt zu stellen. Also, lass uns das tun.

Andreas Klien Bei unserem letzten Treffen in Kopenhagen auf einer Konferenz zur industriellen Cybersicherheit haben wir das Konzept für diese Folge entwickelt. In der Diskussion über Cybersicherheit in der Luftfahrt hast du viele faszinierende Geschichten erzählt. Als jemand, der sich sehr für Flugzeuge interessiert, hat mich auf Anhieb gefesselt. Da kam mir die Idee: Warum nicht den Austausch von Horrorgeschichten über Cybersicherheit in der Luftfahrt vertiefen und sie mit ähnlichen Szenarien im Bereich der Stromnetze vergleichen? Vielleicht können wir so aus den Erfahrungen des jeweils anderen lernen.

Ron Brash Tatsächlich ist die Luftfahrtindustrie ein gutes Beispiel, um die Nuancen von Begriffen wie "sicher" und "unsicher" zu untersuchen, insbesondere im Zusammenhang mit Cybersicherheit. Während der Diebstahl von Kreditkartendaten in herkömmlichen Cybersicherheitsdebatten als unsicher angesehen werden kann, hat der Begriff "unsicher" in der Luftfahrt eine weitaus schwerwiegendere Bedeutung. Im Bereich der kritischen industriellen Cyber-Infrastrukturen, zu denen die Luftfahrt gehört, gibt es ein Bewusstsein für die potenziell katastrophalen Folgen, die oft metaphorisch als "Kraterbildung" bezeichnet werden. Dies unterstreicht, wie wichtig es ist, bei der Verwendung von Begriffen wie "unsicher" in den Bereichen Industrie und Verkehr Vorsicht walten zu lassen.

Die Klärung der Notwendigkeit einer Betriebsunterbrechung oder eines Flugverbots für mobile Betriebstechnik (OT) stellt im Vergleich zur Klärung der Unsicherheit eines Cybersicherheitsereignisses eine besondere Herausforderung dar. Bei letzteren handelt es sich in der Regel um Szenarien wie Verletzungen des Schutzes personenbezogener Daten, Ransomware-Angriffe und andere Bedrohungen, die in der Lage sind, Produktionsstandorte zu unterbrechen - Szenarien, die sich stark von dem unterscheiden, was die Luftfahrtindustrie unter " unsicher " versteht.

In der Luftfahrtindustrie dreht sich die größte Sorge um die " Lufttüchtigkeit ". Die Suche nach Themen wie " Lufttüchtigkeit " und " Flugsysteme " in Suchmaschinen wie Google kann ein überwältigendes Unterfangen sein. In diesem Bereich müssen Aussagen mit absoluter Sicherheit getroffen werden; es ist nicht so einfach, eine CVE-Datei (Common Vulnerabilities and Exposures) zu veröffentlichen, die Kontroversen auslösen könnte. Ein solches Vorgehen ist im Luftfahrtbereich einfach nicht möglich. Jede Entscheidung muss mit akribischer Genauigkeit getroffen werden, wie die jüngsten Vorfälle mit der Boeing 737 zeigen.

Ein entscheidender Punkt ist die Unsicherheit des Herstellers selbst. Es ist beunruhigend, dass zwei Flugzeuge, die nacheinander gebaut und mit identischen Teilen und zertifizierten Komponenten ausgestattet wurden, sich völlig unterschiedlich verhalten können. Selbst wenn derselbe Pilot am Steuer sitzt, können subtile Abweichungen auftreten. Daher müssen alle diese Variablen berücksichtigt werden, wenn der Begriff "unsicher" im Zusammenhang mit der Cyber-Sicherheit diskutiert wird. Jedes Flugzeug erzeugt unterschiedliche Telemetriedaten und ist einzigartig ausgestattet.

Im Luftfahrtsektor habe ich festgestellt, dass alles maßgeschneidert ist und man sich durch komplexe Systeme von Systemen bewegt. Nehmen wir zum Beispiel einen bestimmten Vorfall mit einem Heads-up-Display, vielleicht um 2009 oder 2013. Dieses Head-up-Display von Rockwell Collins war für den Standardeinbau in ein Flugzeug konzipiert, wobei ein zweites Gerät als Option erhältlich war. Beide wurden zertifiziert und als flugtauglich eingestuft. Wenn es jedoch in einem bestimmten Flugzeug installiert und Wi-Fi aktiviert war, schalteten sich beide Displays während des Fluges aus unerklärlichen Gründen ab.

Andreas Klien Sind das diese coolen Glasbildschirme, die wir oft in Dreamliner-Cockpits sehen?

Ron Brash Ja, genau.

Andreas Klien Meinst du die Head-up-Displays oder die, die das Armaturenbrett bilden?

Ron Brash Das Head-up-Display, aber auch das Armaturenbrett. Sie verfügen in der Regel über eine primäre und eine sekundäre Pilotenkonfiguration, wobei in einigen Fällen die sekundäre Option nachträglich eingebaut werden kann, insbesondere bei Fluggesellschaften mit geringerem Budget oder in Entwicklungsländern.

Andreas Klien Ich erinnere mich, dass du Flugzeuge immer als fliegende OT-Standorte (Operational Technology) bezeichnet hast, was eine faszinierende Perspektive ist. Wenn man sie als fliegende OT-Netzwerke betrachtet, die anfällig für Angriffe sind, vor allem am Boden, aber auch in der Luft, bekommt die Diskussion eine faszinierende Dimension. Was mich gerade brennend interessiert, ist deine Aussage, dass Flugzeuge sich nicht einheitlich verhalten. Ich war davon ausgegangen, dass sich Flugzeuge, die in Massenproduktion hergestellt werden, aufgrund identischer Komponenten einheitlich verhalten. Kannst du das näher erläutern? Gibt es Unterschiede in den Komponenten oder ist ein anderer Faktor im Spiel?

Ron Brash Das ist eine fantastische Frage! Wenn man ein Flugzeug direkt vom Hersteller kauft, unterliegt es in der Regel einer Reihe von Standardspezifikationen, die für seine Konstruktion gelten. Diese Spezifikationen legen wichtige Aspekte fest, wie z. B. den Einbau von zwei Pratt & Whitney-Turbinen oder die Auswahl der Avionik, die oft von Firmen wie Honeywell geliefert wird, um z. B. die Bodenkontrolle zu ermöglichen.

Theoretisch sollten alle eingebauten Komponenten genau der vom Hersteller gelieferten Stückliste entsprechen. Es gibt jedoch Spielraum für Anpassungen. Fluggesellschaften können zusätzliche Codes in bestehende Systeme einbauen, um Sicherheitsprotokolle zu verbessern oder die Treibstoffeffizienz zu optimieren. Diese Anpassungen sind für bestimmte Szenarien, wie z. B. Flight- und Thrash-Logik, von entscheidender Bedeutung.

Interessant dabei ist, dass beim Kauf eines Flugzeugs direkt vom Hersteller die Spezifikationen variieren können. Bei der Arbeit an Dreamliner- und Max-Projekten ist mir aufgefallen, dass Flugzeuge unterschiedlich kommunizieren. Stell dir ein zusätzliches Bordunterhaltungssystem vor, das von verschiedenen Herstellern wie Talis oder Panasonic stammen könnte. Im Laufe der Zeit tauchen in den Logs interessante Meldungen auf, wie z.B. "kein Speicherplatz mehr frei" oder "defekte Blitzzelle".

Bei Nachrüstungen gibt es subtile Veränderungen. Ältere Technologien aus verschiedenen Epochen vermischen sich zu einem einzigartigen Verhalten. Und manchmal geschieht etwas wirklich Mysteriöses, wie zum Beispiel eine mysteriöse Shell, die in den Protokollen auftaucht. Niemand kann erklären, warum oder wie das passiert ist.

Die Luftfahrttechnik ist eine faszinierende Mischung aus Präzisionstechnik, Anpassungsfähigkeit und gelegentlichen Überraschungen!

Andreas Klien Ah, das ist ein interessanter Punkt, den du angesprochen hast, nämlich das nachträgliche Einspielen von Code durch die Fluggesellschaft und das Auftauchen der mysteriösen Shell. Ich bin neugierig: Tritt dieses Phänomen nur in nicht-kritischen Netzwerken von Unterhaltungssystemen auf oder erstreckt es sich auch auf tiefere Schichten innerhalb der Flugzeugsysteme?

Ron Brash Im Allgemeinen gibt es im Internet ein Modell, das aus mehreren Schichten besteht und mit einem zeitlich begrenzten Bus arbeitet. Dieser Ansatz beinhaltet Zyklen, die jede Minute stattfinden. Das Konzept ähnelt der Honeywell-Technologie, die in Flugzeugen eingesetzt wird. Wenn du auf solche Netzwerke stößt, wirst du wahrscheinlich nicht in der Lage sein, mit ihnen zu kommunizieren, wenn du nicht verstehst, wie das Protokoll funktioniert. Das Netzwerk besteht aus mehreren Schichten, die sich wie Ringe aufbauen. Je näher du der Avionik und den kritischen Systemen kommst, desto isolierter werden sie. Das Netzwerk arbeitet nach einem Teilnehmermodell, wobei mehrere Firewalls zwischen den Schichten vorhanden sind. Bei Fly-by-Wire-Systemen gibt es jedoch definitiv einige einzigartige Elemente.

Andreas Klien Verstehe, welche anderen erschreckenden Dinge hast du in Flugzeugen schon gesehen?

Ron Brash Oh je! Ich denke, der Hinweis auf die Lufttüchtigkeit unterstreicht meine Bedenken. Heutzutage habe ich mehr Angst vor HF-Angriffen.

Andreas Klien RF steht für Radiofrequenz?

Ron Brash Ja, Radiofrequenzen. Man könnte sich auf Ruben Santa Marta berufen, der eine Art Radarschüssel ist. Ich war in gewisser Weise an der Überprüfung beteiligt, aber einige Dinge stimmten, andere nicht. Aber das hing von jedem Flugzeug und von jedem Flugzeugbetreiber ab; diese Dinge waren alle unterschiedlich. Aber was die Hochfrequenz betrifft, so sind die meisten Flugzeuge nicht für die Abschirmung von innen, sondern für die Abschirmung von außen gebaut.   Und Abschirmung erhöht das Gewicht.Das ist für mich immer ein Grund zur Sorge. Es geht nicht so sehr darum: "Oh, jemand wird das Gespräch gefährden". Nein, das ist es nicht. Es geht darum, dass jemand etwas Katastrophales tut und einen Hochleistungsverstärker in einem Flugzeug einschaltet.

Andreas Klien Das heißt, wenn man aufgefordert werden, alle elektronischen Geräte auszuschalten, wäre das doch ein guter Zeitpunkt, das softwaregestützte Radio einzuschalten, oder?

Ron Brash Früher wohnte ich in der Nähe eines großen Flughafens, direkt an der Einflugschneise. An manchen Tagen tauchte eine seltsame Wolke auf - eine schwere, grüne Masse. Ich bin kein Meteorologe, aber diese Wolke bedeutete Ärger. Als sie auftauchte, standen alle Flugzeuge vor einer kritischen Entscheidung: zu einem anderen Flughafen ausweichen, in einer Warteschleife kreisen, bis sich der Sturm gelegt hat, oder eine Notlandung durchführen.

Aber kommen wir zum Kern der Sache. Wenn sich Piloten für eine schnelle Landung oder einen Notstart entscheiden, betreten sie in diesen kritischen Phasen das gefährlichste Terrain - die operative Ebene. Dabei geht es nicht mehr nur um den Piloten und seine typische Avionik. Vielmehr kommt ein komplexes Netz von Kommunikationskanälen ins Spiel. Stellen Sie sich vor, während Start und Landung laufen Ultrahochfrequenzdaten, GPS-Koordinaten und VHF-Übertragungen zusammen.

Stell dir vor: Die Wolkendecke ist niedrig, die Sicht auf einen Haaresbreite reduziert. Das Flugzeug fliegt im Blindflug und ist auf präzise Anweisungen angewiesen. Aber genau hier wird mir angst und bange. Was passiert, wenn jemand mit softwaregestützen Funkgeräten (SDR) beschließt, Hindernisse - zum Beispiel Ballons - entlang der Flugroute zu platzieren? Diese unkontrollierten Objekte schweben dann gefährlich nahe am sinkenden Flugzeug. Es steht viel auf dem Spiel: gestresste Piloten, schlechtes Wetter und eine ganze Reihe von zweistrahligen Jumbojets, die zur Landung ansetzen.

Es handelt sich also nicht um ein einfaches Cyber-Ereignis. Nein, es ist vielmehr ein komplizierter Tanz der Entscheidungsfindung unter Zeitdruck. Die Operatoren müssen in Bruchteilen von Sekunden Entscheidungen treffen, ihre Nerven sind angespannt. In diesem heiklen Gleichgewicht kann ein einziger Fehltritt zur Katastrophe führen.

Andreas Klien Sicherlich ist das auch eine gängige Strategie von Angreifern: einen kleinen Cyberangriff zu starten, um die Betreiber zu verwirren, damit sie schwerwiegende Fehler machen. Das ist durchaus denkbar. Außerdem sitzen in der Prozesssteuerung, wie überall in der OT, immer Menschen vor den SCADA-Bildschirmen, und wenn sie die falschen Zahlen lesen, treffen sie die falschen Entscheidungen, oder?

Ron Brash Ja, oder sie werden die richtige, sichere Entscheidung treffen. Also den großen roten Knopf zu drücken, und zwar voreilig.

Andreas Klien Auf jeden Fall ist es zumindest ein finanzieller Schaden.

Ron Brash Ja, wenn ich so darüber nachdenke... Andreas, du und ich hatten ein tolles Gespräch über dieses Thema. Ich glaube, es war, als ich dich vor etwa drei Jahren bei einer Veranstaltung kennengelernt habe.

Andreas Klien In einer Podiumsdiskussion. Ja.

Ron Brash Genau, es ging um Eisenbahnsysteme. Wir haben darüber gesprochen, dass in Eisenbahnsystemen häufig Komponenten, wie z. B. Relais, verwendet werden, die auch in anderen Sektoren, nicht nur im Eisenbahnsektor, verwendet werden. Das wirft die Frage auf, inwieweit diese Geräte in verschiedenen Branchen wie Luftfahrt, Eisenbahn und Schifffahrt verwendet werden. Andreas, zum Thema Produktdivergenz und Aufmerksamkeitsverteilung gibt es eine interessante Anekdote. Meiner Erfahrung nach gibt es Fälle, in denen Komponenten, die aus dem industriellen Sektor stammen, unter verschiedenen Namen in verschiedenen Branchen verwendet werden, obwohl sie möglicherweise eine gemeinsame Codebasis haben. Das kann sehr beunruhigend sein. Das bringt mich zum Nachdenken: Welche Unbekannten gibt es im Bereich der Eisenbahnsysteme?

Andreas Klien Ja, in der Luftfahrtindustrie werden in der Tat Automatisierungskomponenten eingesetzt, vor allem am Boden und nicht direkt im Flugzeug. Diese Komponenten stammen aus der Automatisierungsbranche, der mengenmäßig größten Branche, und werden für den Einsatz in anderen Branchen umgewidmet und umbenannt.

So werden z. B. PLC-Komponenten (Programmable Logic Controller), die ursprünglich für die Automatisierungstechnik entwickelt wurden, in der Stromversorgungsindustrie, insbesondere in Umspannwerken, für Aufgaben wie Schutzrelais eingesetzt. Diese Relais, die häufig mit SPS-Modulen ausgestattet sind, werden dann in Eisenbahnsystemen verwendet. Obwohl diese Relais unter verschiedenen Namen und manchmal auch unter verschiedenen Marken vermarktet werden, kann es sich im Wesentlichen um identische Produkte handeln, die mit der gleichen Firmware arbeiten.

Im Eisenbahnsektor ist eine weitere Anpassung aufgrund der Frequenzunterschiede zwischen den verschiedenen Eisenbahnnetzen erforderlich. Während das Standard-Stromnetz mit 50 Hz oder 60 Hz betrieben wird, arbeiten bestimmte Eisenbahnnetze, wie z.B. in Zentral- und Teilen Europas, mit ca. 16,7 Hz. Dies erfordert spezialisierte Produkte mit ähnlicher Firmware, aber möglicherweise unterschiedlichen Konfigurationen oder leicht veränderter Software, die unter verschiedenen Markennamen vertrieben werden.

Trotz dieser Anpassungen sind die zugrunde liegenden Komponenten jedoch häufig mit den gleichen Schwachstellen und ähnlichen Belastungen konfrontiert. Dies wirft die Frage auf, ob alle Schwachstellen angemessen berücksichtigt werden, insbesondere angesichts des Nischencharakters dieser Produkte innerhalb der breiteren Industrielandschaft.

Ron Brash Genau, und es ist nervenaufreibend, mit solchen Szenarien konfrontiert zu werden. Man kann ein Problem in einem Bereich lösen, aber in einem anderen bleibt es bestehen, und das kann ziemlich verwirrend sein. Nehmen wir zum Beispiel den Fall einer bestimmten Line Replaceable Unit (LRU) in einem Dreamliner. Sie ist zufällig identisch mit einer viel größeren und teureren DCS-Einheit (Distributed Control System). Trotz dieser Ähnlichkeit findet man nur selten eine gemeinsame Schwachstelle (Common Vulnerabilities and Exposures, CVE) in der Avionik oder ihrem Pendant in der Luftfahrt.

Andreas Klien Also gibt es doch CVEs für Luftfahrtgeräte?

Ron Brash Normalerweise nicht. Nein. Sie werden in der Regel in Lufttüchtigkeitsberichten veröffentlicht und in aller Stille als Teil einer SOP gehasht oder festgelegt.

Andreas Klien Ich sehe, dass der Umgang mit Softwareproblemen in der Luftfahrt eine große Herausforderung sein muss. Die strengen Sicherheitsstandards erfordern eine gründliche Überprüfung jeder einzelnen Codezeile, fast bis zur mathematischen Gewissheit. Interessanterweise gab es bereits Fälle, in denen Softwarefehler nicht durch eine Aktualisierung des Codes, sondern durch eine Änderung der Hardware selbst behoben wurden. Dieser Ansatz vermeidet die Notwendigkeit kostspieliger Software-Patches und unterstreicht die Komplexität und die Kosten, die mit der Gewährleistung der Software-Integrität in Luftfahrtsystemen verbunden sind.

Ron Brash Im Bereich der medizinischen Geräte besteht eine parallele Herausforderung hinsichtlich der Definition von Änderungen. Diese Geräte basieren häufig auf softwaredefinierten Funktionen, die häufige Aktualisierungen sowohl der Software- als auch der Hardwarekomponenten erfordern. Interessanterweise wird Software zwar als greifbare Einheit behandelt und mit Signaturen versehen, die für eine mögliche Verwendung in Flugzeugen gespeichert werden, aber die Verifizierung dieser Signaturen wird nicht konsequent durchgesetzt.

Die Verwendung verschiedener Programmiersprachen bei der Entwicklung medizinischer Geräte, einschließlich Rust, Ada und ihrer Vorgänger, führt zu unterschiedlichen Ebenen der wissenschaftlichen Validierung. Es bestehen jedoch weiterhin Bedenken hinsichtlich des Vorhandenseins von "maskierenden" Funktionen in der Codebasis, die unbeabsichtigt unnötige Funktionen zurücklassen können.

Die Zertifizierung stellt eine weitere große Hürde dar, insbesondere wenn eine einzige Firmware für mehrere Produktvarianten oder SKUs zertifiziert wird. Dieses Szenario kann zu Schwachstellen führen, wie jüngste Cybersicherheitsvorfälle wie der in Dänemark gezeigt haben. Beispielsweise können bestimmte Geräte mit 3G-Modems von Huawei ausgestattet sein, obwohl diese nicht in der Stückliste der Hardware aufgeführt sind. Solche Diskrepanzen stellen ein Risiko dar, insbesondere in Umgebungen, in denen bestimmte Unternehmen Beschränkungen unterliegen, was die Notwendigkeit einer umfassenden Bedrohungsmodellierung unterstreicht.

Andreas Klien Die Zukunft ist also im Wesentlichen in diesem USB festgelegt. Und es wird nicht in einem SBOM oder sonst etwas erwähnt?

Ron Brash Nein, und es ist beunruhigend, dass die Treiber für diese Huawei-USB-Sticks Open Source sind, d.h. nicht von der Firma selbst, sondern von jemand anderem entwickelt wurden. Beim Kompilieren einer Software Bill of Materials (SBOM) wird normalerweise nur der Linux-Kernel" aufgelistet. Der eigentliche Logikcode des Treibers befindet sich jedoch auf dem USB-Stick von Huawei. Dieser ist zwar oft programmierbar, um ihn an verschiedene Netzbetreiber anzupassen, aber diese Konfiguration birgt ein erhebliches Risiko.

Man stelle sich folgendes Szenario vor: Ein Unternehmen konzentriert sich auf die Verbesserung der Mobilfunkfunktionen, was für die Betreiber von Vorteil sein kann. Ein kleines Unternehmen oder eine Stadt mit begrenzten Ressourcen könnte sich beispielsweise für einen Router mit einem Backup-USB-LTE-Gateway als kostengünstige Lösung entscheiden. Das Problem besteht jedoch darin, dass solche kostengünstigen Funktionen missbraucht werden können, was die Sicherheit des gesamten Systems gefährden könnte.

Dieses Dilemma beschränkt sich nicht nur auf die Telekommunikation, sondern betrifft auch andere Branchen wie die Luftfahrt. Obwohl es wertvolle Informationen über den Schutz kritischer Infrastrukturen gibt, sind die größten Schwachstellen oft auf menschliches Verhalten und den Druck des Kapitalismus zurückzuführen. Die Herausforderung für diejenigen, die sich mit Risikomanagement befassen, besteht also darin, Strategien zu entwickeln, um diese Bedrohungen wirksam zu entschärfen. Und damit sind wir bei einer spannenden Diskussion angelangt.

Andreas Klien Das Risiko, das menschliche Fehler oder Probleme in der Lieferkette verursacht, ist also der Kapitalismus, oder auf was spielst du damit gerade an? 

Ron Brash Ja, der Kapitalismus ist die Wurzel aller Cybersicherheitsprobleme. 

Andreas Klien Ja, in gewisser Weise stimmt das. Aber er ist zusätzlich auch der Feind aller Sicherheitsmaßnahmen, oder? Denn Sicherheitsmaßnahmen sind eine Investition auf Zeit. Wenn man nur die Sicherheit verbessert, hat man nicht wirklich viel davon, keine neuen Features und dergleichen. Also ist er im Grunde immer der Gegner von Sicherheitsmaßnahmen. 

Ron Brash Ja, das Übel allem Übels.

Andreas Klien Ja, das ist richtig. Eine weitere Frage, die ich jetzt habe, wo wir gerade bei den Risiken in der Lieferkette sind. Wie können wir Risiken in Lieferketten identifizieren? Du analysierst seit vielen Jahren die Firmware. Wie können wir Risiken in der Lieferkette identifizieren?

Ron Brash Angriffe auf die Lieferkette sind ein komplexes Thema, das wichtige Fragen über den Ursprung des Angriffs und seine Auswirkungen aufwirft. Nehmen wir zum Beispiel einen Angriff, bei dem die Software eines ukrainischen Buchhaltungsunternehmens infiziert und dann als Verbreitungsmechanismus verwendet wird, ähnlich dem Vorfall bei SolarWinds. Ist der Zulieferer das Ziel des Angriffs oder betrifft er die gesamte Kette von Anfang bis Ende?

Diese Ungewissheit macht es schwierig, die mit Angriffen auf die Lieferkette verbundenen Risiken zu erkennen und zu mindern. Verschiedene Szenarien erfordern verschiedene Strategien. Betrifft das Problem die Hardware, die Software oder beides? Handelt es sich um eine Frage des Wissenstransfers oder der Verteilung innerhalb der Lieferkette? Dies sind alles entscheidende Überlegungen, für die es keine klare Taxonomie gibt, wie Eric Buyers in seinem aufschlussreichen Vortrag zu diesem Thema feststellte.

Im Allgemeinen werden Angriffe auf die Lieferkette mit der Manipulation von Open-Source-Komponenten in Verbindung gebracht. Für Anlagenbetreiber kann es jedoch einschüchternd sein, Einblick in solche Schwachstellen zu erhalten und zu erfahren, wie sie darauf reagieren sollen. Selbst wenn bekannt ist, dass eine bestimmte Version von OpenSSL verwundbar ist und angegriffen wird, ist es nicht einfach, die richtige Vorgehensweise zu bestimmen.

Dennoch gibt es Maßnahmen, die ergriffen werden können. Sichtbarkeit ist der Schlüssel, aber ebenso wichtig ist die Fähigkeit, auf der Grundlage dieser Sichtbarkeit Maßnahmen zu ergreifen. Dies könnte bedeuten, dass man seine Risikomanagement-Strategie überdenkt und Maßnahmen zur Verteidigung in der Tiefe einbezieht. Technologische Vielfalt kann Kosten verursachen, ist aber oft eine notwendige Investition in die Widerstandsfähigkeit.

Die Bewältigung von Risiken in der Lieferkette bedeutet auch, sich von der völligen Abhängigkeit von einzelnen Lieferanten zu lösen. Wählen sie langlebige Produkte und stellen sie sicher, dass die Lieferanten alle Komponenten regelmäßig aktualisieren. Behandelt das Risiko in der Lieferkette wie das Risiko von Dritten und erkennt die Interdependenz aller Beziehungen in der Kette an.

Die Komplexität der Geschäftswelt stellt eine weitere Herausforderung dar. Lieferanten können ihre Namen ändern, und das Rebranding von Produkten kann ihre Herkunft verschleiern. Diese Feinheiten unterstreichen die Herausforderung, Risiken in der Lieferkette effektiv zu managen.

Dies ist ein schwieriges Thema, auf das es keine einfachen Antworten gibt, aber wenn wir die damit verbundene Komplexität verstehen, können wir beginnen, diese Herausforderungen effektiver anzugehen.

Andreas Klien Danke für dieses Beispiel. Kannst du unseren Zuhörern, die mit der Luftfahrtindustrie nicht so vertraut sind, einen kurzen Überblick über die Netzstruktur eines OT-Netzes (Operational Technology) rund um einen Flughafen geben, insbesondere im Hinblick auf die Anbindung von Flugzeugen an dieses Netz?

Ron Brash In einem einfachen Flughafen mit nur einigen Türen, durch die die Passagiere das Rollfeld betreten, sind mehrere miteinander verbundene Systeme in Betrieb. Man stelle sich Folgendes vor: Wenn ein Passagier den Flughafen betritt, trifft er auf Kioske, an denen er sein Gepäck aufgeben und Tickets kaufen kann. Mit diesem ersten Schritt beginnt die Reise der IT/OT-Konvergenz.

Sobald das Gepäck mit einem Etikett versehen ist, wird es von einem System aus automatischen Förderbändern und Bildverarbeitungsgeräten durch den Flughafen geleitet. Unterwegs werden Sicherheitsmaßnahmen wie Grenzkontrollen und Röntgenscanner durchgeführt.

Wenn der Koffer in das Flugzeug verladen wird, durchläuft er in einem weiteren Schritt Barcode-Scanner. Währenddessen kommunizieren verschiedene Systeme an Bord des Flugzeugs mit der Flugsicherung im Tower.

Bemerkenswert ist, dass Details über das Gepäck eines Passagiers auf der IT-Seite den Start des Flugzeugs beeinflussen können. Dies verdeutlicht die Vernetzung der Systeme in der Luftfahrt.

Während des Fluges steht das Flugzeug mit den Bodensystemen in Verbindung, und bei der Landung erleichtern ähnlich vernetzte Systeme die sichere Ankunft und Abfertigung von Passagieren und Gepäck. Die Luftfahrt ist eine der am stärksten vernetzten und sicherheitskritischen Branchen, in der eine Vielzahl von Systemen nahtlos zusammenarbeiten.

Andreas Klien Interessant! Im Stromnetz sind die Netze eher baumartig strukturiert, mit der Leitstelle an der Spitze, die den Betrieb der Anlagen und Umspannwerke überwacht. Die Leitstelle hat Schnittstellen zu Hilfsnetzen für IT-Dienste und Betriebstechnik (OT). Von der Leitstelle aus folgen die Verbindungen einem Top-Down-Ansatz und erreichen die Purdue-Ebene 1, wo Steuerungen und Schutzrelais die Anlagen verwalten.

Während die unteren Ebenen des Netzes weniger miteinander verbunden sind, besteht eine erhebliche Interkonnektivität zwischen der Leitstelle und den umliegenden verteilten Überwachungs- und Steuerungssystemen (Distributed Monitoring and Control, DMC). Diese DMCs verarbeiten Aufgaben wie Smart-Meter-Daten und Gerätekonfigurationsdateien, was einen Datenaustausch auch während der Arbeit vor Ort erfordert.

Temporäre Geräte wie Laptops von Ingenieuren sind wichtige Angriffsvektoren auf den unteren Ebenen des Netzwerks. Trotz der geringeren Vernetzung gibt es mehr Verbindungen als oft angenommen. Beispielsweise werden bei der Installation von Intrusion-Detection-Systemen häufig mehrere externe TCP/IP-Verbindungen zu Geräten der Purdue-Ebene 2 oder der virtuellen Ebene 1 festgestellt.

Die Teams unterschätzen häufig die Anzahl der vorhandenen Verbindungen, da sie davon ausgehen, dass ihre Verbindung die einzige ist. In Wirklichkeit gibt es in der Regel mehrere Verbindungen, einschließlich der Verbindungen des Schutztechnikteams, des SCADA-Teams und des Netzwerkteams, das die Switches verwaltet.

In einem bemerkenswerten Fall hatte ein großes Umspannwerk mehr als 60 externe IP-Adressen mit permanenten Verbindungen zu Geräten. Dies warf Fragen nach der Notwendigkeit und der Sicherheit auf, zumal Schwachstellen in einem alten Beispielserver entdeckt wurden, der dazu verwendet wurde, Konfigurationsdateien direkt in Relaisverzeichnissen abzulegen.

Diese Schwachstellen machen deutlich, wie wichtig eine gründliche Bewertung und ein Risikomanagement sind, insbesondere in kritischen Infrastrukturumgebungen, in denen viel auf dem Spiel steht.

Ron Brash Ja, das kommt ziemlich häufig vor. Ob es sich um Samba oder andere Protokolle handelt, Sie werden oft ähnliche Schwachstellen finden. Selbst bei älteren Industriegeräten sind FTP-Drops oder Debugger als Teil der Board-Support-Packages aktiviert. Dies gilt auch für ältere Relays und Packages. Dies macht sie anfällig für Malware oder andere böswillige Aktivitäten, insbesondere wenn sie durch technische Software in eine vermeintlich sicherere Umgebung zurückversetzt werden. Dieses Szenario ist auch bei DCS-Geräten (Distributed Control System) weit verbreitet, wo primäre und sekundäre Server auf Windows basieren und Konfigurationen ohne ordnungsgemäße Validierung akzeptieren können.

Andreas Klien FTP gilt weithin als veraltetes und unsicheres Protokoll. Wenn man heute einen FTP-Server im Einsatz sieht, ist das oft ein Grund zur Sorge, da er idealerweise durch eine sicherere Alternative wie SFTP ersetzt werden sollte. Aber auch Protokolle, die in OT-Umgebungen (Operational Technology) eingesetzt werden, können erhebliche Risiken bergen, manchmal sogar mehr als ein ungepatchter oder sogar gepatchter FTP-Server.

Ein Beispiel ist das RMS-61850-Protokoll, das aus den 1970er oder 1980er Jahren stammt. Ursprünglich ein OSI-Protokoll, wurde es später an TCP/IP angepasst, was zu einer komplexen Architektur mit zusätzlichen Schichten über den sieben Standardschichten führte. Diese Komplexität macht es anfällig für Schwachstellen und Sicherheitsprobleme und gleicht einem Wolkenkratzer mit mehreren Schichten potenzieller Schwachstellen.

Ron Brash Tatsächlich gibt es im Bereich der Netzleitsysteme (NMS) verschiedene Dialekte und Versionen, jede mit ihren eigenen Nuancen und potentiellen Gefahren. Genauso wie die englische Sprache aufgrund unterschiedlicher Akzente oder Interpretationen kein gegenseitiges Verständnis garantiert, können unterschiedliche Versionen von NMS zu Missverständnissen oder Schwachstellen führen.

Diese Variationen von NMS können sich auf verschiedenen Ebenen des Protokollstapels manifestieren und zu Komplexitäten führen, die nicht unbedingt sofort erkennbar sind. Fuzzing oder destruktive Tests, bei denen absichtlich versucht wird, Systemfunktionen zu stören oder zu manipulieren, können Fälle aufdecken, in denen protokollinhärente Einschränkungen oder Mehrdeutigkeiten zu unerwartetem Verhalten führen. In einigen Fällen können diese Probleme nicht nur auf die Interaktion zwischen dem Protokoll und den Geräten, mit denen es eine Schnittstelle bildet, zurückzuführen sein, sondern auch auf inhärente Schwächen des Protokolls selbst.

Andreas Klien Ich habe einmal in einem Team gearbeitet, das einen neuen 650-Client-Stack für ein DMS-Protokoll (Distribution Management System) entwickelt hat. Wir entwickelten ihn von Grund auf neu und veröffentlichten ihn als Update für ein Produkt mit einer großen Benutzerbasis. Trotz ausgiebiger Tests mit verschiedenen Geräten unterschiedlicher Hersteller weltweit sind wir bei der Veröffentlichung auf unerwartete Probleme gestoßen.

Viele Anwender berichteten, dass ihre kritischen Schutzrelais abstürzten, wenn sich unser Client-Stack mit ihnen verband, das war so um 2014 herum. Unser Client-Stack verhielt sich standardkonform, aber die Geräte waren nicht mit unserem Client als Referenz programmiert, was zu unerwartetem Verhalten führte. Zum Beispiel hatten die Entwickler der älteren Relais nicht damit gerechnet, dass Anfragen aus Effizienzgründen gebündelt werden würden.

Da die Geräte im Feld nicht gepatcht werden konnten, mussten wir unseren Client so modifizieren, dass er sich anpasste und die Geräte nicht abstürzten. Dies war jedoch aufgrund der vielen Bugs und Schwachstellen in den bestehenden Implementierungen eine Herausforderung. Wir haben weiche Modi eingeführt, z.B. einen übervorsichtigen Modus, um Risiken zu minimieren und Abstürze zu vermeiden. Wir haben auch einen "Keep Close"-Modus für bestimmte Geräte eingeführt, um die Stabilität zu gewährleisten.

Auch heute noch aktivieren wir diese Modi in unseren Produkten, wenn wir ein ähnliches Verhalten feststellen, um Stabilität zu gewährleisten und Ausfälle zu vermeiden.

Ron Brash Ja, das stimmt! Viele ältere Architekturen, insbesondere solche, die für serielle Kommunikation entwickelt wurden, waren nicht auf die Komplexität moderner Netzwerkumgebungen vorbereitet. Zum Beispiel waren ältere Durchflussmesser und Überwachungsgeräte wie Honeywell Mercury Zähler nur für den physischen Zugriff konzipiert und berücksichtigten nicht das "Cocktail-Party-Problem" mit mehreren Lautsprechern.

Mit dem Aufkommen von Protokollen wie 61850, die im Wesentlichen auf verschiedenen anderen Protokollen wie seriell und TCP basieren, wird die Herausforderung noch größer. Diese Protokolle wurden ursprünglich nicht für die gleichzeitige Kommunikation einer großen Anzahl von Netzwerkgeräten entwickelt. Daher können ältere Geräte Schwierigkeiten haben, wenn sie mit einer schnellen und gleichzeitigen Kommunikation von mehreren Clients konfrontiert werden.

Die Zustandsautomaten in diesen Geräten sind nicht für solch schnelle Interaktionen ausgelegt, was zu unerwartetem Verhalten führt, wenn mehrere Clients gleichzeitig zu kommunizieren versuchen. Grenzfälle wie die gleichzeitige Verarbeitung von mehr als zehn Clients oder das Pipelining von Paketen wurden bei den Tests oft übersehen.

Grundsätzlich wurden viele dieser älteren Architekturen nicht im Hinblick auf robuste Tests entwickelt, was zu Schwachstellen und unerwartetem Verhalten in modernen Netzwerkumgebungen führt. Dies zeigt, wie wichtig gründliches Testen und die Berücksichtigung von Grenzfällen bei der Entwicklung neuer Architekturen und Protokolle sind.

Andreas Klien Ja, das ist wahr. Vor allem, wenn man immer nur an eine Art von OT-System denkt. Und im Laufe der Jahre wird das Produkt dann in verschiedenen Anwendungen eingesetzt. Und dann sind plötzlich andere Einsatzszenarien möglich. Die Produkte, die duvorhin erwähnt hast, diese Boxen in der seriellen Implementierung, welche sind das zum Beispiel?

Ron Brash Es gibt einige bemerkenswerte Geräte, wie zum Beispiel die Honeywell Mercury-Geräte, die jetzt Teil der gesamten Honeywell-Marke sind. Ich kenne den genauen Modellnamen nicht, aber viele der früheren Geräte basierten auf Windows CE. Es gibt auch andere serielle Geräte, wie z.B. Durchflussmesser aus dem Emerson-Katalog, die als Rosemont-Serie bekannt sind. Diese seriellen Protokolle werden oft über TCP-Gateways weitergeleitet, die auch OPC classic und andere Protokolle wie Dicom und SMB verwenden können. Dies ist üblich, aber viele Geräte, besonders im DCS-Arbeitsbereich, haben Telnet-Verbindungen, die sorgfältig gehandhabt werden müssen. Ein Gerät, an dem ich gearbeitet habe, der Bachman und PC 40, stammte beispielsweise vom grauen Markt eines Frachtschiffs und wurde zur Steuerung des Wasserballasts verwendet. Wenn Telnet-Verbindungen nicht richtig gehandhabt wurden, stürzten der Telnet-Server und andere Peripheriegeräte ab, und das Gerät musste neu gestartet werden. Sogar nicht böswillige Aktivitäten können Ihre Geräte stören, wenn sie nicht ordnungsgemäß getestet wurden.

Andreas Klien Das passiert immer wieder. Und zwar in vielen Umspannwerken mit älteren Geräten, die aber trotzdem schon auf dem 61850-Protokoll basieren. Ein Denial-of-Service-Angriff würde aus nur zehn SIM-Paketen bestehen. Man öffnet also zehn Verbindungen und dann wird jede weitere Verbindung blockiert. Man kann keine weitere Verbindung öffnen. Es handelt sich also um einen Denial-of-Service-Angriff mit zehn Paketen.

Ron Brash Dies weist auf eine interessante Sache für Leute hin, die versuchen, Ideen zur Risikoprävention zu bekommen. Einer der häufigsten und besten Orte, um nach dieser Art von Informationen zu suchen, sind meiner Meinung nach nicht die CVEs. Vielmehr sind es die Hardware-Fehlermeldungen, die vom Hersteller kommen. Einige Anbieter erstellen ständig Änderungsprotokolle und geben an, was sie an ihrem Produkt verbessern. Sie werden feststellen, dass es oft viele Formulierungen gibt, die auf ein Cybersicherheitsproblem hinweisen, aber nicht als solches deklariert sind. Zum Beispiel führt ein Modbus-Paket mit diesem Bereich und diesem Code zu einem Loch in der CPU. Das ist ein großes Problem, denn man hat den Hackern gerade gesagt, wie sie ihren Exploit-Code schreiben sollen. Die bedanken sich.

Andreas Klien Genau! 

Ron Brash Dies wird jedoch nicht als ZUE ausgewiesen.

Andreas Klien Denn niemand hat es als Sicherheitslücke gemeldet. Es wurde nur als Fehler gemeldet.

Ron Brash Ja, genau. Ich schaue mir diese Dinge oder die Hardware oft an, besonders wenn ich die CPU kenne. Es gibt eine Menge Hardware. Wenn du denkst, dass Specter schlecht ist. Das ist gar nichts. Es gibt all diese Hardware-Meldungen, wenn man nachts lange aufbleiben will. Ich suche gerne nach unsicherer Architektur, weil man sie sehr schnell sieht.

Andreas Klien Der Bedarf an robusten Cyber-Security-Praktiken erstreckt sich über alle Branchen, wobei Pufferüberlauf-Schwachstellen ein großes Problem darstellen. In verschiedenen Branchen werden bei der Überprüfung von Errata-Seiten und bei der Untersuchung von Systemabstürzen häufig Fälle von Pufferüberläufen entdeckt. Diese Schwachstellen, die aus einer unzureichenden Eingabevalidierung oder Grenzwertprüfung resultieren, sind die Ursache vieler Systemausfälle und Sicherheitsverletzungen. Die Behebung von Pufferüberlaufmöglichkeiten ist daher von entscheidender Bedeutung, um potenzielle Cyber-Sicherheitsrisiken zu verringern und die Integrität und Stabilität von Systemen in verschiedenen Branchen zu gewährleisten.

Ron Brash Ich verwende gerne Wörter wie "Errata" und technische Begriffe, weil die meisten unserer Mitarbeiter und Anlagenbediener einen Hintergrund in Maschinenbau und Elektrotechnik haben. Wenn also jemand technische Begriffe wie "Buffer Overflow" erwähnt, übersetze ich das mit "Gerät funktioniert nicht mehr". Genauso bedeutet 'Watchdog' 'Problem beim Neustart der Maschine'. Ich brauche diese Probleme in meinem Prozess nicht, also setze ich Prioritäten bei der Behebung dieser Probleme. Es geht darum, das Vokabular so anzupassen, dass man sich auf Sicherheit, Zuverlässigkeit und Produktivität konzentriert. Man muss kein Experte für Cyber Security sein, man muss nur die möglichen Auswirkungen auf die Geräte verstehen. Den Unterschied zwischen einer 'http'- und 'https'-Verschlüsselung zu kennen, ist vielleicht nicht so wichtig, aber zu verstehen, dass bestimmte Sicherheitslücken zum Absturz eines Geräts führen können, ist entscheidend und sollte unmittelbar berücksichtigt werden.

Andreas Klien In der Tat. Der häufigste Grund für das Einspielen von Patches ist die Behebung von Fehlern und Ausfällen. Die Behebung von Sicherheitslücken durch Patches ist mit Vorsicht zu genießen, da sie betriebliche Risiken mit sich bringt. Liegt jedoch bereits ein betriebliches Problem vor, wird die Aktualisierung der Firmware dringlicher.

Das bringt mich zu meiner letzten Frage: Hast du Empfehlungen für branchenübergreifende Best Practices? Vielleicht können wir unsere Ergebnisse hier zusammenfassen und mögliche Vorteile der Übernahme von Praktiken aus der Luftfahrtindustrie zur Verbesserung der Sicherheit im Stromnetz aufzeigen.

Ron Brash Es gab viele Diskussionen über das Purdue-Modell und seine Sicherheitseinschränkungen, neben den nützlichen ISA-62443-Modellen. Die Dokumentation der Luftfahrtindustrie für Bodensysteme ist den Empfehlungen für industrielle Leitsysteme (Industrial Control Systems, ICS) und industrielle Automatisierung und Steuerung (Industrial Automation and Control, IAC) sehr ähnlich, aber die Luftfahrt unterscheidet sich in einigen Aspekten.

Ein bemerkenswerter Unterschied ist die Abhängigkeit von GPS für Zeit und Daten, was nicht ideal ist, da es nur einen Kanal und eine Quelle hat. Die Luftfahrt legt Wert auf Redundanz mit mehreren Zeit- und Kommunikationskanälen, was bei Ereignissen wie Waldbränden, die das Stromnetz unterbrechen können, besonders wichtig ist.

Eine weitere wertvolle Lektion aus der Luftfahrt ist die strikte Politik gegen temporäre Laptops, insbesondere für Techniker und Dritte. Auf Flughäfen, die häufig von Auftragnehme:innen genutzt werden, ist es wichtig, genau zu wissen, welche Geräte vorhanden sind, und sicherzustellen, dass sie sauber und sicher sind.

Auch die Luftfahrt geht mit gutem Beispiel voran, indem sie Flugzeuge nicht als Wegwerfartikel betrachtet, sondern für ihren gesamten Lebenszyklus plant. Kritische Infrastrukturen sollten eine ähnliche Haltung einnehmen, indem sie erkennen, dass Anlagen im Laufe der Zeit verschleißen und Übergänge planen, um die Widerstandsfähigkeit zu erhalten.

Darüber hinaus unterscheidet sich der Ansatz der vorausschauenden Wartung und Kontrolle in der Luftfahrt von den traditionellen Methoden, da die Verfügbarkeit von Ersatzteilen und proaktive Maßnahmen im Vordergrund stehen. Diese untypischen Empfehlungen regen zu einem Umdenken an, um die Widerstandsfähigkeit und Bereitschaft in kritischen Infrastruktursektoren zu verbessern.

Andreas Klien Vielen Dank, Ron. Ich denke, wir haben gute Arbeit geleistet, indem wir einige erschreckende Geschichten über Bugs und Schwachstellen und technische Szenarien für die Luftfahrt, aber auch für die Energieindustrie zusammengetragen haben. Möchtest du zum Schluss noch etwas hinzufügen?

Ron Brash Es war mir wirklich ein Vergnügen, hier zu sein und mich wieder mit dir zu treffen, Andreas. Ich bin dankbar, dass ich keinen 11-stündigen Flug auf mich nehmen musste, um zu dir zu kommen. Wenn mir jemand zufällig bei einer Veranstaltung über den Weg läuft oder weiß, dass ich in der Stadt bin, zögert bitte nicht, mich zu kontaktieren. Ich würde mich freuen, mit euch ein Getränk zu teilen und zu plaudern.

Andreas Klien Gut gemacht. Ich danke dir. In diesem Fall übergebe ich das Wort wieder an Scott.

Scott Williams Danke Andreas and Ron für diese informative Unterhaltung. Und ein großes Dankeschön an unser Publikum fürs Zuhören. Wir freuen uns immer über eure Fragen und euer Feedback. Sendet uns einfach eine E-Mail an podcast@omicronenergy.com.

Seid euch bei der nächsten Folge von Energy Talks wieder dabei. Bis dahin, alles Gute und auf wiedersehen! 

Hören Sie rein (Englisch)