95 % der Betreiber kritischer Infrastrukturen übersehen diese drei Schwachstellen – gehören Sie dazu?

95 Prozent der Unternehmen haben genau diese drei Schwachstellen in ihren IIoT-Systemen. Habt ihr sie auch? In dieser Folge spreche ich mit Klaus Mochalski. Er hat die Security-Branche von Grund auf mitgestaltet und bringt über Jahre hinweg erprobte Best Practices aus der Industrie mit. Er ist Strategic Advisor und Gründer der Firma Rhebo. Rhebo ist Experte für den Bereich Cybersicherheit und bietet entsprechende Monitoring-Lösungen. Wir beantworten diese Frage und noch einige mehr: Was sind die Top 3 Use Cases für typische Schwachstellen in eurem System? Was empfiehlt Klaus für eure IIoT-Sicherheitsstrategie? Die NIS2-Richtlinie kommt – seid ihr vorbereitet, und wenn ja, wie? Und ein weiterer spannender Aspekt zum Schluss: Künstliche Intelligenz in der Security. Ist das nur ein Hype oder bringt es echten Mehrwert? Wenn ja, welchen genau? Das erfahrt ihr jetzt – anhand eines Kundenbeispiels aus dem Bereich erneuerbare Energien.

Hallo Klaus, herzlich willkommen zum IoT Use Case Podcast. Ich freue mich sehr, dass du heute dabei bist, weil du selbst Podcast-Host bist. Darüber können wir gleich sprechen. Herzlich willkommen.

Klaus

Hallo Madeleine, danke für die Einladung. Es macht mir auch viel Spaß, heute hier zu sein und mal auf der anderen Seite zu stehen. Ich freue mich auf unser Gespräch.

Jetzt muss ich kurz persönlich nachfragen: Du bist in verschiedenen Bereichen unterwegs. Bei LinkedIn steht, du bist Entrepreneur, Strategic Advisor und Founder bei Rhebo. Was hat es mit der Entrepeneurship auf sich?

Klaus

Ich hatte dort vor kurzem noch stehen, dass ich CEO von Rhebo bin, und nichts anderes. Ich bin aber tatsächlich vor knapp zwei Jahren als Geschäftsführer bei Rhebo ausgeschieden. Danach hatte ich ein Jahr, ich nenne es ein „Working Sabbatical“, mit meiner Familie im Ausland. In dieser Zeit habe ich mein Geschäftsführeramt niedergelegt, Rhebo aber weiterhin als strategischer Berater begleitet. Damit dort nicht nur „Berater“ steht, habe ich „Entrepreneur“ ergänzt, weil ich bis heute schon drei Firmen gegründet habe: die erste 2005, Rhebo als dritte Firma im Jahr 2014. Deshalb finde ich, darf ich das legitimerweise von mir behaupten.

Da müssen wir gleich noch ein bisschen tiefer einsteigen. Ich bin ja selbst auch in einer ähnlichen Rolle unterwegs. Und noch kurz: Wie kam es dazu, dass du Podcast-Host geworden bist? Das macht ja nicht jeder. Hattest du einfach Lust darauf oder wie ist das entstanden?

Klaus

Ich muss sagen, das war schon eine Diskussion, die wir auch bei uns im Marketing-Team bei Rhebo hatten, ob das ein Format ist, das wir gut finden. Ich habe das aber von Anfang an unterstützt, weil ich selbst Podcast-Hörer bin. Ich finde, das ist ein großartiges Format, losgelöst von all dem Videocontent, den man heute hat, weil man es so bequem nebenbei hören kann, ohne andere zu stören und ohne ein Endgerät vor dem Gesicht halten zu müssen. Deswegen fand ich das von Anfang an gut. Dann haben wir ein wenig experimentiert, sind da recht unprofessionell gestartet, machen das aber mittlerweile immer professioneller und regelmäßiger. Mir macht es derzeit großen Spaß mit den verschiedenen Gästen. Inzwischen sind wir in einer Art zweiter Staffel, viele Gäste waren bereits mehrfach bei uns. Mittlerweile kommen auch Gäste aktiv auf uns zu und möchten dabei sein. Das hat sich sehr gut entwickelt, und wir werden das auf jeden Fall weiterführen.

Für alle, die jetzt zuhören und Lust haben reinzuhören: „OT Security Made Simple“ – ich packe euch den Link in die Shownotes. Hört unbedingt mal rein! Ich war selbst auch schon zu Gast, deshalb freut es mich besonders. Jetzt hast du ja schon angesprochen, es geht natürlich auch um die Firma dahinter, Rhebo. Vielleicht steigen wir kurz ein in eure Firma. Wir kommen später nochmal auf eure Kunden und den Markt zu sprechen. Heute geht es ja um erneuerbare Energien, aber auch um die Anlagen dahinter. Ganz kurz zu Rhebo: Ihr seid Anbieter von OT- und IIoT-Security-Lösungen, insbesondere mit einer speziellen Anomalieerkennung. Ich glaube, wie eure Kunden das nutzen, schauen wir uns gleich noch genauer an. Kannst du uns ein wenig über euch und vor allem über eure Kunden erzählen? In welchem Markt seid ihr unterwegs?

Klaus

Rhebo ist 2014 gestartet, und wir waren von Anfang an ein reiner OT- und Industrial-IoT-Security-Anbieter. Wir sind also nicht aus der IT-Security herausgewachsen, wie viele andere Player am Markt, sondern haben direkt mit dem Ziel begonnen, OT-Anlagen – also industrielle Steuerungssysteme im weitesten Sinne – zu schützen. Das war von Anfang an unser Optimierungsziel. Das System, das wir unseren Kunden heute anbieten, ist im Prinzip noch immer das gleiche, das wir damals entwickelt haben. Die Idee hat sich weiterentwickelt, aber nicht grundlegend verändert. Wir überwachen die Kommunikation in vernetzten digitalen industriellen Anlagen, konkret in OT-Anlagen. Wir nutzen Algorithmen, um die Kommunikation zu erlernen und zu verstehen, wie sie im Normalbetrieb aussieht. Im Dauerbetrieb überwachen wir diese dann kontinuierlich und suchen nach Abweichungen. Du hattest es schon erwähnt: Anomalieerkennung. Immer wenn es Veränderungen in den Kommunikationsmustern gibt, versuchen wir herauszufinden, ob diese Veränderungen zu Störungen oder Ausfällen der Anlage führen könnten. Am Ende verkaufen wir unseren Kunden eine Früherkennung von Ereignissen, die zu einem Ausfall führen können. Das können sowohl Sicherheitsvorfälle sein als auch technische Störungen. Viele unserer Bestandskunden, die das System ursprünglich für Cybersecurity-Zwecke angeschafft haben, sehen heute auch den Mehrwert in der Erkennung technischer Störungen. Diese generieren ebenfalls Anomalien in der Kommunikation, und dieser Aspekt liefert oft sogar den größeren Mehrwert, weil er dazu beiträgt, die Lebensdauer des Systems zu verlängern, indem alle Störungsursachen in der Kommunikationsinfrastruktur erkannt werden können.

Ich denke, wir sprechen da gleich nochmal genauer drüber. Mich interessiert vor allem, was die konkreten Use Cases sind und welche Schwachstellen ihr identifiziert, insbesondere aus Sicht eurer Kunden. Ich glaube, das interessiert auch viele, die jetzt zuhören. Vielleicht vorab noch ganz kurz: Ihr seid ja vor allem im KRITIS-Segment unterwegs, habt aber auch viel Industrie dabei. Kannst du mal beschreiben, was das für Anlagen sind, die ihr euch im Bereich der Erneuerbaren anschaut? Nur als Beispiel: Sind das Windenergieanlagen, bestimmte Wasserkraftwerke, oder ist das egal? Betrachtet ihr da jegliche OT-Anlagen?

Klaus

Wir sind da relativ anlagenagnostisch. Es gibt technisch natürlich manchmal Unterschiede, aber am Ende spielt das eine eher geringe Rolle. Was du sagst, stimmt. Unsere Kernzielgruppe ergibt sich auch aus der Regulierung und der Gesetzeslage in Deutschland und Europa. Unsere Kunden waren von Anfang an Unternehmen, die aufgrund des IT-Sicherheitsgesetzes KRITIS-reguliert sind und dort spezielle Anforderungen erfüllen müssen. Das waren zunächst vor allem große Energieversorger und große Verteilnetzbetreiber. Mit der Zeit kamen immer mehr kleinere Unternehmen dazu. Jetzt geht es auch in Richtung mittelgroße Stadtwerke und mit der kommenden NIS2-Regulierung wird das noch breiter werden. Die Kunden werden kleiner, und darauf müssen wir uns als Anbieter mit unseren Produkten und Dienstleistungen natürlich einstellen. Erneuerbare Energieanlagen sind da automatisch Teil des Ganzen, weil jeder große Energieversorger solche Anlagen selbst betreibt. Es gibt dabei auf technischer Seite spezifische Herausforderungen, auf die wir gerne noch im Detail eingehen können. Wir haben uns oft gefragt, was die beste Art ist, solche Anlagen zu überwachen. Gerade bei erneuerbaren Energieerzeugungsanlagen haben wir es häufig mit verteilten Strukturen zu tun, und das ist ein zentraler Unterschied. Während ein Betreiber von Kraftwerken vielleicht zwei, drei oder fünf große Anlagen hat, die sich zentral und relativ einfach überwachen lassen – dort installieren wir unsere Sensorik vor Ort im Kraftwerk oder Umspannwerk, und diese Sensoren liefern ihre Anomaliedaten an ein zentrales Security-Dashboard – sieht es bei erneuerbaren Anlagen anders aus. Wenn ich zum Beispiel 30 Windparks betreibe, oder noch kleinteiliger auf die einzelnen Turbinen blicke, die potenziell ebenfalls Angriffspunkte sein können, dann sprechen wir plötzlich von bis zu 3.000 Einheiten. Da kann man sich vorstellen, dass es nicht möglich ist, in jede einzelne Turbine einen Sensor einzubauen, um sie lokal zu überwachen. Da braucht es andere Ansätze, um diese Funktionalität effizient vor Ort bereitzustellen.

Jetzt hören hier sicherlich auch einige aus der Produktion zu. Es betrifft ja nicht nur Windparkbetreiber, sondern auch produzierende Unternehmen, die beispielsweise PV-Anlagen auf dem Dach betreiben oder andere erneuerbare Energiequellen nutzen. Das ist aktuell ein zentrales Thema in Politik und Wirtschaft. Ich möchte gar nicht zu politisch werden, aber es ist definitiv auch für produzierende Betriebe relevant, die Daten aus erneuerbaren Energiequellen in ihren gesamten Energiemix einzubinden. Ihr fokussiert euch also nicht ausschließlich auf Windparkbetreiber.

Klaus

Absolut. Diese Anlagen sind in der Vergangenheit häufig aus der KRITIS-Regulierung herausgefallen, weil es sich von der Kapazität her eher um kleinere Anlagen gehandelt hat. Es gab immer Diskussionen und Einflussnahmen der Lobbygruppen bei den konkreten Grenzwerten, die dann auch in der Novellierung des IT-Sicherheitsgesetzes gelandet sind. Dort ist geregelt, ob die Einzelanlagenkapazität ausschlaggebend ist – dann würden viele Anlagen herausfallen, da sie im PV- und Windbereich oft kleiner sind – oder ob die gesamte Anlagenkapazität zählt. In dem Fall sind sie wieder drin. Wir haben ja alle gehört, dass Deutschland im vergangenen Jahr einen sehr hohen Anteil seines Stroms aus erneuerbaren Energien erzeugt hat – über 50 Prozent waren das. Damit wird das automatisch zu einer kritischen Infrastruktur, und diese Anlagen müssen geschützt werden. Selbst im kleineren Maßstab betrifft das viele Industriebetriebe. Ein Beispiel ist BASF, die auf Windkraft setzen und eigene Anlagen installieren, um das Werk in Ludwigshafen mit Strom zu versorgen. Auch das wird dann zu einer kritischen Ressource, und diese muss geschützt werden wie jede andere kritische Ressource im Unternehmen.

Da gibt es natürlich auch einige Herausforderungen – gerade beim Ausbau der erneuerbaren Energien, was Netzstabilität oder Speichermöglichkeiten betrifft. Ich weiß, heute wollen wir auf das Thema Security fokussieren. Wenn ihr Interesse habt: Ich habe dazu bereits eine Podcast-Folge aufgenommen, es war Folge 136 mit RIZM. Wir haben dort zwei spannende Beispiele vorgestellt – eines mit Schaeffler, da ging es um die Produktion zu optimalen Energiepreisen, und eines mit BMW, bei dem es um die intelligente Optimierung von Investitionen in Energiesysteme auf Basis von Daten ging. Wer tiefer einsteigen möchte, gerne dort reinhören. Jetzt möchte ich aber den Bogen zur Frage spannen: Warum sprechen wir heute überhaupt über Security? Du hast es schon angesprochen – es geht um NIS2. Vielleicht können wir kurz erklären, was es damit auf sich hat und warum wir im Kontext erneuerbarer Energien überhaupt über Security sprechen. Lass uns gerne dort starten – erst einmal mit NIS2. Im Kern ist es ja eine Richtlinie, bei der es darum geht, dass Unternehmen Überwachungsmaßnahmen haben müssen und auch nachweisen müssen, dass sie IT-Security-Anforderungen umsetzen.

Klaus

Ganz genau. NIS2 baut auf der ursprünglichen NIS-Direktive auf. Ich habe vorhin schon öfter das IT-Sicherheitsgesetz in Deutschland erwähnt – das basiert direkt auf der Umsetzung dieser ersten NIS-Direktive, die einige Jahre älter ist als NIS2. Diese Direktiven werden von der EU vorgegeben und müssen von jedem Mitgliedsstaat in nationales Recht überführt werden. Das hat in allen Mitgliedsländern stattgefunden. NIS2 ist jetzt eine Verschärfung und vor allem eine Erweiterung in Bezug auf die Reichweite. Das heißt, es sind deutlich mehr Sektoren betroffen und vor allem auch kleinere Unternehmen. Die Schwellenwerte liegen, soweit ich es im Kopf habe, bei etwa 50 Millionen Euro Umsatz und 50 Mitarbeitern. Da kann man sich leicht ausrechnen, dass ein großer Teil des deutschen Mittelstands darunterfällt – und das auch völlig zurecht. In Deutschland ist NIS2 allerdings noch nicht umgesetzt. Unsere aktuellen Regierungsprobleme haben dazu geführt, dass es nicht mehr durch das Parlament gegangen ist. Die Annahme ist, dass es im besten Fall im Laufe des Sommers, spätestens aber gegen Ende des Jahres, umgesetzt werden wird. Danach gibt es eine Übergangsfrist von etwa zwei Jahren, bis auch geprüft werden kann, inwiefern Unternehmen diese Anforderungen erfüllen.

Wenn wir das in die Praxis übertragen – was bedeutet das für mich als Windparkbetreiber, wenn ich beispielsweise 30 Parks betreibe, oder auch als produzierendes Unternehmen? So wie ich es verstanden habe, muss ich mir Gedanken machen: Wie gehe ich mit meinen Schwachstellen um? Wie etabliere ich Prozesse, um solche Schwachstellen zu erkennen und zu überwachen? Kannst du das noch einmal erklären? Was bedeutet das konkret für einen Betrieb in der Praxis?

Klaus

Ich sage es mal ganz polemisch und plakativ: Theoretisch bedeutet das gar nichts. Wer seine Anlagen vernünftig betreibt und eine Risikoabschätzung durchführt – so wie jede Geschäftsleitung es für alle geschäftsbedrohenden Faktoren tun sollte – ist bereits auf der sicheren Seite. Wenn man Windenergieanlagen installiert, muss man analysieren, welche Wetterphänomene diese beschädigen könnten. Das Gleiche gilt für PV-Anlagen. Man sichert sich gegen finanzielle Risiken ab und wägt grundsätzlich alle potenziellen Gefahren für das Geschäft ab. Man quantifiziert diese Risiken und entscheidet, ob bei bestimmten Bedrohungen, die entweder sehr wahrscheinlich sind oder drastische Konsequenzen hätten, Maßnahmen ergriffen werden müssen. Das kann eine Versicherungspolice sein oder technische Schutzmaßnahmen – und genau das gilt auch für Cybersecurity.

Wer seine Hausaufgaben in diesem Bereich gemacht hat, muss eigentlich nicht viel ändern. Aber konkret und konstruktiv: Was bedeutet das nun in der Praxis? Zunächst – und das ist auch so in den Regulierungen festgehalten – muss ich eine Risikoanalyse durchführen und ein Informationssicherheitsmanagement-System etablieren. Das sollte aber ohnehin selbstverständlich sein. Es ist keine überzogene Anforderung, sondern eine Notwendigkeit. Ich sollte im Cybersecurity-Bereich meine Risiken kennen und dokumentieren. Zudem braucht es definierte Handlungsanweisungen, Verantwortlichkeiten und Prozesse, um bei einem Vorfall nicht in Chaos zu verfallen.

[14:22] Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus

Was sind typische Use Cases? Welche Schwachstellen treten häufig auf und welche sollte man sich auf jeden Fall anschauen, um eine fundierte Risikoabschätzung durchführen zu können?

Klaus

Ja, absolut. Zunächst möchte ich sagen: In den Bereichen, in denen wir aktiv sind – häufig das KRITIS-Umfeld, also dort, wo wir wirklich kritische Infrastruktur überwachen – kommt es relativ selten zu echten Vorfällen. Das bedeutet, wir lesen oft mehr in der Presse darüber, als wir von unseren eigenen Kunden hören. Und das ist auch gut so. Trotzdem gibt es eine gewisse Diskrepanz zwischen der geringen Häufigkeit tatsächlicher Vorfälle und der hohen Häufigkeit von Schwachstellen, die wir bei unseren Kunden finden. Diese Schwachstellen sind potenzielle Einfallstore für Angriffe. Das Risiko schätzen wir also deutlich höher ein als das, was tatsächlich passiert. Wir haben dazu aber oft nur anekdotische Informationen. Vielleicht können wir später noch über einen konkreten Fall sprechen, den wir wirklich beobachtet haben. Was wir jedoch systematisch und empirisch beobachten, sind Sicherheitsrisiken – also Schwachstellen in Infrastrukturen. Diese wurden zwar schon vielfach beschrieben, aber wir quantifizieren sie seit Jahren bei unseren Kunden. Für das letzte Jahr kann ich die häufigsten Schwachstellen nennen, die wir gefunden haben. Wir veröffentlichen regelmäßig eine Top-Ten-Liste, und daraus möchte ich jetzt die drei häufigsten Punkte herausgreifen. Interessanterweise treten diese drei mit nahezu identischer Häufigkeit auf – wir haben sie bei etwa 95 Prozent unserer Kunden festgestellt, bei denen wir Sicherheitsanalysen durchgeführt haben. Das sind unnötige Protokolle und Dienste. Das bedeutet, wir finden in Infrastrukturen, die einem klaren Zweck dienen – zum Beispiel der Steuerung eines Windparks – Kommunikationsprotokolle und Softwaredienste, die im Netz aktiv sind, aber gar nicht benötigt werden. Die Empfehlung aus Best-Practice-Sicht lautet hier immer: Alles, was nicht gebraucht wird, abschalten. Denn jede unnötige Komponente bietet eine zusätzliche Angriffsfläche.

Okay, das heißt konkret: Ich habe beispielsweise in meinem Solarpark oder bei den Steuerungen meiner PV-Anlage auf dem Dach Protokolle und Dienste, die nicht benötigt werden oder die fehlerhafte Informationen liefern? Was genau ist in diesem Zusammenhang die Herausforderung?

Klaus

Ein Beispiel könnte sein: Wir haben eine komplette IPv4-Infrastruktur und sehen dort drei oder vier Systeme, die mit IPv6 kommunizieren. Das ist an sich erst einmal kein Problem, aber es bietet eine zusätzliche Angriffsfläche für potenzielle Angreifer. Vermutlich ist dieser IPv6-Teil auch schlechter gemanagt und möglicherweise von der Firewall nicht so gut abgesichert wie der IPv4-Bereich. Ein anderes Beispiel: In Produktionsumgebungen haben wir schon WhatsApp-Kommunikation festgestellt, weil es dort Möglichkeiten gibt, über eine USB-Verbindung Zugang zum Produktionsnetz zu erhalten. Plötzlich kommunizieren private Endgeräte im Produktionsnetz – das ist natürlich ein enormes Sicherheitsrisiko. Das war der erste Punkt der Top 3. Der zweite Punkt sind sogenannte untypische Kommunikationsmuster im OT-Bereich. OT-typische Kommunikationsmuster umfassen alles, was mit Messen, Steuern und Regeln zu tun hat. Dabei handelt es sich um Industrieprotokolle, über die Kontrollsysteme mit Sensoren und Aktoren kommunizieren, Daten auslesen und Steuerbefehle senden. Diese Datenmengen sind sehr gering und es handelt sich meist um einen konstanten Datenstrom. Das sieht ganz anders aus als üblicher Internetverkehr und verhält sich in allen Anlagen sehr typisch. Wenn dort plötzlich Kommunikationsmuster auftauchen, die eher in einer Büroumgebung zu erwarten wären, wird das auffällig. Ein Beispiel ist Backup-Software. Grundsätzlich ist Backup-Software sinnvoll, aber durch fehlerhafte Netzwerkkonfigurationen kann das Steuerungsnetz mit Backup-Kommunikation überlastet werden. Dabei kommt es häufig zu einer Beeinträchtigung der Echtzeitkommunikation. Im OT-Bereich ist das Timing entscheidend – nicht das Volumen. Steuerungsbefehle müssen teilweise innerhalb von Millisekunden oder sogar Mikrosekunden ankommen, gerade in automatisierten Fertigungsstraßen mit Robotern im Taktbetrieb, wie beispielsweise in der Automobilindustrie. Wenn ich nun über ein ohnehin bandbreitenschwaches Steuerungsnetz Gigabytes oder sogar Terabytes an Backups übertrage, kann das zu erheblichen Störungen führen. Wir beobachten im OT-Bereich oft, dass grundlegendes IT-Know-how und Best Practices fehlen. Außerdem gibt es immer wieder Diskrepanzen in der Zusammenarbeit zwischen den Verantwortlichen für die Anlagen und den IT-Abteilungen.

Das ist ja ein typisches Phänomen: IT und OT wachsen zusammen. Aber okay, der zweite Case betrifft also die OT-typischen Kommunikationsmuster, wie du sie beschrieben hast – insbesondere die Kommunikation zwischen Sensoren und Aktoren, die eher auf der Feldebene stattfindet, und das Beispiel, das du gerade genannt hast.

Klaus

Genau. Und dahinter steht eine Best-Practice-Empfehlung, die sich in der Community zunehmend etabliert: Die strikte Trennung von IT- und OT-Infrastrukturen. Das muss man etwas erklären, denn es wird immer von Konvergenz gesprochen und davon, dass diese Welten zusammenrücken – und das stimmt auch. Aber obwohl die Netze mittlerweile digital miteinander verbunden sind, sollten sie organisatorisch ganz klar getrennt bleiben. Es braucht vor allem ein Sicherheitskonzept, das die unterschiedlichen Sicherheitsanforderungen in beiden Bereichen definiert, denn diese unterscheiden sich grundlegend. Das muss man konsequent umsetzen. In der Regel geschieht das durch strikte Netzwerkssegmentierung und den Einsatz entsprechender Firewalls. So hat man auf der einen Seite die reine OT-Kommunikation und auf der anderen Seite die IT-Kommunikation. Wenn es hier einen Austausch gibt, dann muss dieser ganz klar geregelt und kontrolliert ablaufen.

Ja, absolut wichtig. Wenn ihr jetzt zuhört und denkt: super spannend, wir haben ähnliche Herausforderungen oder würden uns gerne mal austauschen – Klaus, wenn das für dich okay ist, würde ich deinen LinkedIn-Kontakt einfach in die Shownotes packen. Dann könnt ihr euch direkt vernetzen und Best Practices austauschen. Gerade das Thema, wie man diese organisatorische Trennung in der Praxis umsetzt und was das für den Betrieb bedeutet, interessiert mich auch sehr. Da könnten wir wahrscheinlich sogar nochmal eine eigene Podcast-Folge draus machen. Also gerne Kontakt aufnehmen. Jetzt interessiert mich natürlich noch der dritte Case. Was wäre das für einer?

Klaus

Der dritte Punkt basiert auf den häufig veralteten Softwareversionen, die in diesem Bereich verwendet werden. Es wird ja viel darüber gesprochen, dass in Steuerungssystemen teilweise noch Windows XP oder sogar Windows 95 im Einsatz ist. Wir haben das Thema mittlerweile feiner aufgedröselt. Früher haben wir einfach gesagt: „Alte Software“. Heute wissen wir, dass diese veraltete Software so viele unterschiedliche Probleme verursacht, dass wir als wichtigsten Punkt unsichere Authentifizierungsmethoden identifiziert haben. Das hängt natürlich oft direkt mit alter Software zusammen. Dahinter verbirgt sich Software, die beispielsweise Nutzernamen und Passwörter unverschlüsselt über das Netzwerk überträgt oder kryptografische Verfahren verwendet, die nicht mehr den aktuellen Sicherheitsstandards entsprechen. Ein Angreifer kann diese Schwachstellen mit frei verfügbaren Standard-Tools innerhalb von Sekunden ausnutzen. Wir sehen das relativ häufig. Ein konkretes Beispiel: unverschlüsselte Telnet- und FTP-Kommunikation, bei der Passwörter im Klartext übertragen werden. Dafür gibt es im Jahr 2025 keine Entschuldigung mehr, denn es existieren längst sichere Alternativen. So etwas sollte man definitiv nicht mehr in seiner Infrastruktur betreiben.

[22:10] Lösungen, Angebote und Services – Ein Blick auf die eingesetzten Technologien

Jetzt brennt mir eine Frage unter den Nägeln, und ich möchte das vorziehen. Wir hatten vorhin über Anomalieerkennung gesprochen, und du hast erwähnt, dass es bestimmte Algorithmen dafür gibt. Diese Risikoabschätzung kann man ja auch datenbasiert vornehmen. Kannst du kurz erklären, wie ihr das bei Rhebo macht beziehungsweise wie eure Kunden das Thema angehen? Ich habe verstanden, dass ihr eine Top-10-Liste von Angriffs- bzw. Schwachstellenrisiken identifiziert habt. Wie geht man das in der Praxis an? Wie unterstützen eure Kunden diesen Prozess?

Klaus

Wenn es sich um Neukunden handelt, unterstützen wir diese, indem wir mit einer Sicherheitsanalyse starten. Das bedeutet: Wir installieren unsere Sensorik – das kann entweder ein Software-Agent sein oder auch ein Hardware-Gerät, das wir in der Infrastruktur integrieren. Dann lassen wir das System zunächst für einen definierten Zeitraum, in der Regel zwei Wochen, einfach passiv mitlaufen. In dieser Zeit werden alle Kommunikationsdaten erfasst, und das System lernt, wie die Kommunikation im Normalbetrieb aussieht. Im Anschluss nimmt sich ein Experte aus unserem Team, der solche Analysen täglich durchführt – wir haben dafür ein festes Team, das auch im Dauerbetrieb unsere Kunden unterstützt – diese Daten vor und prüft, ob es Auffälligkeiten gibt. Es gibt bestimmte Muster und Anomalien, die das System automatisiert erkennt. Aber da das Spektrum der Anlagen, die wir überwachen, und die möglichen Schwachstellen sowie Angriffsszenarien sehr vielfältig sind, verlassen wir uns nicht allein auf maschinelle Intelligenz. Wir analysieren die Daten immer auch manuell, um sicherzustellen, dass wir nichts übersehen. Gerade bei Neukunden betreten wir Infrastrukturen, die oft viele Jahre, manchmal Jahrzehnte in Betrieb sind, mit einem breiten Spektrum unterschiedlichster Systeme. Deshalb gehört ein manueller Anteil immer dazu. Wir wollen eine vollständige Analyse gewährleisten, bei der wirklich alle Auffälligkeiten erfasst werden. Anschließend besprechen wir gemeinsam mit dem Kunden, was uns aufgefallen ist. Viele der zuvor genannten Beispiele stammen genau aus diesen Analysen – das sind unsere empirischen Daten. Im nächsten Schritt erörtern wir dann, was konkret zu tun ist: ob es um Netzsegmentierung, Patching oder den Austausch von Komponenten geht, muss individuell bewertet werden.

Du bist ja jetzt schon sehr lange in dem Bereich unterwegs. Was sind denn deine persönlichen Erfahrungen aus diesen Projekten? Ihr betreut ja ganz unterschiedliche Kunden, und da gibt es sicher viele Fallstricke oder Dinge, auf die man achten muss. Was sind typische Situationen, bei denen du denkst: „Hätten wir mal früher gesprochen“ oder „Hier wurde Geld für Dinge ausgegeben, die nicht notwendig gewesen wären“? Was sind deine persönlichen Erfahrungen?

Klaus

Das größte Problem, das ich über die Jahre immer wieder sehe und das bis heute besteht, ist interessanterweise kein technisches, sondern ein personelles. Und das hat verschiedene Facetten. Zum einen gibt es viel zu wenige Experten, die sich an der Schnittstelle zwischen dem Betrieb von Industrieanlagen und IT-Security wirklich gut auskennen. Es gibt also nur wenige Personen, die dieses Know-how in einer Person vereinen. Das bedeutet, es müssen immer Teams zusammenarbeiten. Diese Teams haben jedoch oft unterschiedliche Prioritäten. Für einen Betreiber einer Anlage, eines Windparks oder einer automatisierten Fertigung liegt die oberste Priorität darauf, dass die Anlage stabil läuft und es nicht zu Ausfällen kommt. In der IT hingegen stehen Datenschutz und Datensicherheit im Fokus. Hier kommt es zum ersten „Clash of Cultures“. Viele Organisationen ringen noch damit, wie sie sich dort am besten aufstellen und zusammenarbeiten. Es gibt Modelle, die sich bei großen Unternehmen etabliert haben. Aber gerade bei kleineren Unternehmen fehlt es häufig an Strukturen und Personal. Deshalb ist es aus meiner Sicht enorm wichtig, sich vertrauenswürdige Dienstleister ins Boot zu holen – gerade für kleinere Organisationen. Für mich ist der größte Engpass tatsächlich der Fachkräftemangel, auch wenn man es oft hört und viele es nicht mehr hören können. Aber auch die Zusammenarbeit zwischen den verschiedenen Teams innerhalb einer Organisation bleibt eine große Herausforderung.

Und die Kunden, die sich entschieden haben, mit euch zusammenzuarbeiten – ich weiß nicht, ob wir sie namentlich nennen dürfen, ich kenne einige aus unseren Vorgesprächen – was war bei denen der ausschlaggebende Punkt? Ich könnte es ja auch intern lösen, aber wie du sagst, Fachkräftemangel ist ein großes Problem. Alternativ kann ich sagen: Ich hole mir externe Unterstützung, zum Beispiel eure Lösungen. Was waren die Beweggründe eurer Kunden, sich für diese externe Lösung zu entscheiden? Was ist der Business-Case dahinter?

Klaus

Der ursprüngliche Auslöser für eine Investitionsentscheidung ist häufig das Thema Compliance – also regulatorische Vorgaben, die erfüllt werden müssen. Der zweite große Faktor ist das Kapazitätsproblem. Das hat sich über die Jahre stark entwickelt. Wir hatten früher viele Kundengespräche, in denen es hieß: „Wir betreiben das System selbst. Unsere IT-Abteilung kümmert sich darum. Wir brauchen keinen zusätzlichen Service.“ Und tatsächlich hat Rhebo vor sechs Jahren noch keinen eigenen Service angeboten. Wir haben das System als Plattform verkauft, und die Kunden haben es selbst betrieben. Große Energieversorger, die tausende Anlagen überwachen, haben dafür auch eigene Teams. Aber wenn man sich ein Stadtwerk einer 200.000-Einwohner-Stadt anschaut, wo vielleicht zwei oder drei Personen in der IT-Abteilung arbeiten, ist es fraglich, ob dort wirklich die Kapazität und das Know-how vorhanden sind, um das System eigenständig zu betreiben. Genau aus diesem Grund haben wir unseren Serviceanteil über die Jahre immer weiter ausgebaut. Heute ist es unser Standardangebot, ein Gesamtpaket aus Plattform und Dienstleistungen anzubieten. Diese Dienstleistungen können unterschiedlich ausgestaltet sein. Es gibt die Möglichkeit der reinen Unterstützungsleistung – der Kunde betreibt das System selbst, und wir helfen bei Bedarf, etwa bei einer forensischen Analyse nach einem Vorfall. Es gibt aber auch Kunden, die den Betrieb komplett an uns übertragen. In diesen Fällen übernehmen wir die Rolle eines SOC (Security Operations Center) und überwachen kontinuierlich den Strom an Anomaliedaten, den unser System in der Kundeninfrastruktur generiert. Bei kritischen Vorfällen melden wir uns aktiv beim Kunden.

Okay, sehr gut. Compliance bedeutet in dem Fall also gesetzliche Vorgaben zur IT- und OT-Sicherheit, Schutzmaßnahmen, die umgesetzt werden müssen, sowie Anforderungen, die dazukommen. Das ist also der Haupttreiber. Und ihr bietet den Firmen die Möglichkeit, diese Anforderungen gemeinsam mit euch umzusetzen – sowohl durch euren Service als auch durch eure Produkte. Das betrifft dann auch die Anomalieerkennung, die du vorhin angesprochen hast. Wenn ich es richtig verstanden habe: Ihr installiert die Lösung, dann analysiert ein Experte über einen gewissen Zeitraum die Daten und schaut, welche Auffälligkeiten es gibt. Anschließend besprecht ihr gemeinsam mit dem Kunden, wo es Schwachstellen gibt und welche Maßnahmen sinnvoll wären. Das ist also sowohl als Serviceleistung als auch als Softwarelösung verfügbar, richtig?

Klaus

Genau. Wir haben ja bereits über die Sensorik gesprochen. Das bedeutet, wir installieren Sensoren an verschiedenen, potenziell sehr vielen Punkten in der Infrastruktur des Kunden. Diese liefern ihre Daten an ein zentrales System, in dem alle Anomalieinformationen zusammenlaufen. Dort gibt es ein zentrales Dashboard, das wir im ersten Schritt bereitstellen. Das ist die Benutzeroberfläche unseres Systems. Auf diesem zentralen Bildschirm laufen alle Anomaliemeldungen ein, die man im Detail analysieren und daraus entsprechende Maßnahmen ableiten kann. Bei Kunden, die schon weiter fortgeschritten sind und das System stärker integriert haben, läuft es oft so, dass sie gar nicht mehr direkt auf unser Dashboard schauen. Stattdessen werden die Daten weitergeleitet an ein SIEM-System – ein Security Information and Event Management System –, das möglicherweise bereits im Betrieb ist. Vielleicht existiert dort sogar schon ein eigenes SOC, in dem verschiedene Systeme zusammengeführt werden. Auf den großen Bildschirmen in solchen Räumen laufen dann die Daten aller Sicherheitssysteme zusammen – von Firewalls, Servern und eben auch von unserer Anomalieerkennung. Das ermöglicht es, die Daten zu korrelieren und Angriffe intelligenter und schneller zu erkennen. Viele Unternehmen stehen hier allerdings noch ganz am Anfang. Aber die Möglichkeit besteht, unsere Meldungen vollständig in solche zentralen Systeme zu integrieren.

Schaut gerne mal auf der Website von Rhebo vorbei – rhebo.com. Dort findet ihr weitere Informationen, und auch der Podcast ist dort verlinkt. Ich selbst habe noch viele weitere Fragen, aber das würde vermutlich den Rahmen dieser Folge sprengen. Deshalb möchte ich dir zum Abschluss noch eine letzte Frage stellen: Das Thema Security und Anomalieerkennung entwickelt sich stetig weiter. Gerade Künstliche Intelligenz ist derzeit ein großes Thema. Wo siehst du in diesem Bereich die Zukunft? Worauf sollten Betriebe achten? Womit beschäftigt ihr euch bei Rhebo in dieser Hinsicht? Hast du einen Ausblick darauf, was künftig relevant wird?

Klaus

Ein wichtiges Thema, das uns bei Rhebo immer beschäftigt, ist die Frage, wie wir in der Fülle an Meldungen über Veränderungen in Anlagen – gerade in großen Infrastrukturen – die relevanten von den weniger relevanten Daten trennen. In der Vergangenheit haben wir das meist mit deterministischen Methoden gelöst, weil die Kommunikation in diesen Systemen relativ stabil und deterministisch ist. KI-Systeme hingegen arbeiten mit Wahrscheinlichkeitsaussagen. Sie erkennen Muster und sagen mit einer gewissen Wahrscheinlichkeit, dass das, was gerade beobachtet wird, einem Angriff ähnelt, den sie aus der Datenbank kennen. Wir haben lange Zeit gesagt, dass Wahrscheinlichkeitsaussagen für solche kritischen Systeme nicht ausreichen. Je nachdem, wie man eine KI justiert, filtert sie bestimmte Dinge heraus und bewertet sie als nicht relevant – was sich im Nachhinein aber als Fehleinschätzung herausstellen kann. Deshalb haben wir über Jahre hinweg diese Daten ungefiltert weitergegeben und viel investiert in eine möglichst intelligente Aufbereitung der umfangreichen Informationen, sodass sie trotzdem für einen Menschen gut verarbeitbar bleiben. Künftig wird hier aber mehr und mehr KI ins Spiel kommen – allerdings als unterstützendes Werkzeug.

Also im Prinzip, um zu unterscheiden, ob es sich um relevante oder eher irrelevante Daten handelt. Mit KI könnte man also unterstützen und sagen: „Schau hier nochmal genauer hin.“ Ist das so gemeint?

Klaus

Ganz genau. Das funktioniert wie eine Art Vorfilterung. Vergleichbar mit der Medizin: Niemand möchte, dass eine KI die endgültige Diagnose stellt und entscheidet, ob operiert wird oder nicht. Aber sie hilft dem Arzt dabei zu erkennen, wo er genauer hinschauen sollte. Genauso ist es auch bei uns. Die KI markiert bestimmte Punkte in den Datensätzen, aber am Ende muss immer noch ein Mensch drüber schauen, bevor man beispielsweise entscheidet, die Kommunikation zu einem Kraftwerk abzuschalten.

Vielen Dank schon einmal für den Ausblick in Richtung Zukunft. Die Zeit ist superschnell verflogen, und ich habe, wie gesagt, noch einige weitere Fragen. Wenn ihr jetzt Interesse habt, nehmt gerne Kontakt zu Klaus auf. Ich würde mich natürlich auch freuen, in Zukunft noch einmal eine weitere Folge dazu zu machen. Ansonsten erst einmal vielen Dank für deine Zeit heute. Ich fand es sehr spannend. Ein Punkt ist noch offen – vielleicht kann ich den in die Shownotes packen. Du hattest vorhin erwähnt, dass ihr zwischen Risiken bzw. Schwachstellen und echten Angriffen und Vorfällen unterscheidet und da etwas angeteasert. Vielleicht kann ich dazu noch einen konkreten Case in die Shownotes einfügen. Von meiner Seite aus erst einmal vielen lieben Dank. Man hat heute sehr gut verstanden, wie ihr das Thema löst, warum es wichtig ist, was die Markttreiber sind und welche die Top 3 Use Cases sind. Vielen Dank für diese konkrete Vorstellung! Ich übergebe dir gerne das letzte Wort, falls du noch etwas ergänzen möchtest. Vielen Dank, dass du heute dabei warst!

Klaus

Das hast du sehr schön zusammengefasst. Mir hat es auch Spaß gemacht – es war eine sehr kurzweilige Diskussion. Ich möchte alle Zuhörer ermutigen, den Kontakt zu suchen. Ich freue mich über Kommentare, Hinweise und den Austausch. Und tatsächlich haben wir es heute nicht mehr geschafft, über den konkreten Angriff zu sprechen. Vielleicht schaffen wir das in einer nächsten Episode. Vielen Dank für die Einladung und die spannende Diskussion!

Sehr schön. Danke dir, Klaus, und eine schöne Restwoche! Mach’s gut, ciao.

Klaus

Tschüss!