Passives OT-Monitoring: Angriffe erkennen, bevor es kritisch wird

Heute im IoT Use Case Podcast: Cybersecurity in der OT, also in der Betriebstechnologie. Dabei erfahren wir, was passives Zuhören im Cybersecurity-Kontext bedeutet und wie das mit dem Red Team funktioniert. Zu Gast haben wir die Firma Rhebo aus Sachsen mit ihrem Vertriebsleiter Jan Fischer. Viele sprechen von IT/OT-Konvergenz, wir sprechen heute über die Gründe, dieses Zusammenspiel nicht allzu eng zu gestalten. Viel Spaß dabei.

Hallo und herzlich willkommen zum IoT Use Case Podcast. Ich bin euer Podcast Co-Host Dr. Peter Schopf, gerne Peter für euch, wir sind hier unter uns. Ich bin die Vertretung von Madeleine Mickeleit. Wer noch mehr über mich erfahren möchte, kann einfach eine Folge zurückspringen, wir haben neulich eine Sonderfolge aufgenommen. Bevor wir uns jetzt ausführlicher vorstellen, Jan, an dich: Warum sollten uns die Hörer heute bis zum Ende zuhören?

Jan

Weil das Thema Cybersecurity extrem spannend ist. In den Nachrichten sieht man jede Woche und jeden Monat neue Meldungen über Versuche, Infrastrukturen zu kompromittieren. Es ist ein extrem heißes und spannendes Thema, über das wir uns unbedingt austauschen sollten.

Super, ich freue mich auch sehr auf die Folge. Cybersecurity ist nicht so mein Spezialgebiet. Umso gespannter bin ich auf die Hintergründe, wie man das genau aufsetzt und was alles schiefgehen kann. Da haben wir sicher ein paar Geschichten, die wir besprechen können. Aber erzähl doch ein bisschen ausführlicher von dir, Jan. Was machst du, wo sitzt du, wie lange bist du schon bei der Firma und hast du im Bereich Cybersecurity auch einen technischen Hintergrund?

Jan

Sehr gern. Mein Name ist Jan Fischer. Ich bin bei der Firma Rhebo als Head of Sales angestellt. Ich verantworte den Vertrieb national und international, außerdem den Bereich Presales und Teile unserer Support-Struktur, also die Zusammenarbeit mit den Entwicklerteams. Ich bin jetzt seit über drei Jahren bei der Firma. Davor war ich viele Jahre, über eine Dekade, in dem IT-Konzern Dell Technologies tätig und habe dort fast jede Rolle kennengelernt, vom Innendienst über den Außendienst bis hin zu weiteren Funktionen, und habe viele Erfahrungen mit zu Rhebo gebracht. Auch hier als Head of Sales bin ich nicht nur im Innendienst und orchestriere, sondern ich arbeite direkt mit Kunden zusammen. Ich höre den täglichen Bedarf und das, was Sorgen und Nöte sind, aus den Strukturen des Supports und aus den Entwicklerteams. Ich lebe die Hands-on-Mentality und sehe unser Produkt im Live-Einsatz. Ich nutze es auch selbst gern zu Präsentationszwecken über eine Webdemo, in der man ein erstes Look-and-Feel bekommt. Wie sieht es aus, wenn ich mich für Rhebo entscheide, wie arbeite ich damit und wo kann ich für mich sinnvolle Ergebnisse ableiten, die ich mit dieser Software gewinne?

Ich finde es sehr spannend, dass ihr euch im Bereich Cybersecurity auf die OT-Seite spezialisiert. Bei IT-Cybersecurity gibt es ja viele Firmen. OT ist deutlich spezieller. Wie unterscheidet ihr euer Angebot im Markt, was ist euer Unique Selling Point?

Jan

Das Besondere, unser Unique Selling Point, ist unser Gesamtansatz. Wir verfügen nicht nur über die passende Software, sondern auch über den passenden Service. Das bedeutet, gerade wenn man über Cybersecurity in der OT spricht, also in der Betriebstechnologie, bewegt man sich in einer etwas anderen Kerninfrastruktur im Unternehmen, sei es in der Industrie oder bei Energieversorgern. Ich befinde mich hier in einem Umfeld mit einer relativ starren Infrastruktur. Diese ist historisch gewachsen und wird nicht stark verändert, weil in der OT nicht tagtäglich ein neues Protokoll entworfen wird und auch nicht jeden Tag ein neues Asset auf den Markt kommt, das viele Neuerungen verspricht. Man hält bewusst an Dingen fest, die etabliert sind und nicht so einfach zu kompromittieren, weil man bereits gehärtete Systeme vorfindet.
Das bedeutet, unser Unique Selling Point ist das Zusammenspiel aus Software und Service. So sind wir auch einzigartig platziert. Wir unterstützen nicht nur mit Service im Sinne von „so läuft unsere Software“, sondern wir können tatsächlich Hilfestellung leisten, wenn es um Forensik und Diagnose geht. Wenn ich einen Vorfall habe, stehe ich nicht allein da und muss nicht meine Kernressourcen aus dem Tagesgeschäft herausziehen, salopp gesagt. Ich kann sagen: Jetzt rufe ich Rhebo an und hole mir die Hilfe, die ich brauche.

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

Was sind die ersten Signale, die Kunden mit eurer Software entdecken? Wo greift euer Service als erstes? Worauf wird man aufmerksam gemacht, wenn es wirklich zu einem Incident, also zu einem Vorfall kommt?

Jan

Genau. Wir nehmen an, wir haben heute eine Infrastruktur, die ist mit unserer Software verheiratet. Das bedeutet nicht, dass man sich keine anderen Hersteller anschauen könnte. Aber wir kennen diese Infrastruktur und unser System arbeitet mit den Erkennungsmustern, die dort bekannt sind. Es weiß: Es gibt ein Verhalten, das typisch ist, und es gibt ein Verhalten, das atypisch ist.
Sobald eines meiner Assets eine Netzwerkkommunikation verursacht, die unbekannt ist, also wenn zum Beispiel ein neues Protokoll genutzt wird, nehmen wir an, es gibt eine Abweichung von Profinet, und plötzlich wird nicht mehr Profinet gesprochen, sondern ein veraltetes Profibus. Dann ist das eine Veränderung vom typischen hin zu einem atypischen Verhalten. Sofort schlägt unser System an und meldet: Hier gibt es eine Anomalie. Diese ist nicht quittiert, das heißt, sie ist unbekannt und stellt eine potenzielle Gefahr dar.
Im ersten Schritt habe ich also die Kennzeichnung einer Gefahr. Im zweiten Schritt habe ich die Möglichkeit, mir den Mitschnitt anzusehen. Alles, was an Kommunikation innerhalb eines festgelegten Intervalls stattfindet, wird aufgezeichnet und liegt als PCAP vor. Das ist im Prinzip eine Kurzaufzeichnung wie ein Recording. Man kann sehen: Was wurde gesprochen, von wem, zu wem wurde es gesprochen. Ich sehe beide Vermittlungsstellen, die angesprochen wurden, und den Traffic, der verursacht wurde.
Jetzt kann ich sagen: Anhand dieses PCAPs schicke ich die Daten zu Rhebo und möchte wissen, was dort genau passiert ist, wenn ich es selbst nicht einordnen kann. Dann gibt es verschiedene Möglichkeiten. Ich kann das mit Wireshark analysieren und mir anzeigen lassen, was innerhalb des PCAPs passiert ist. Welche Protokolle wurden gesprochen? Welche Ports sollten erreicht werden? Welches Protokoll war es genau? All das sehe ich einmal im Controller, also unserer primären Instanz, aber auch sehr detailliert in der PCAP-Datei. Jeder, der Wireshark noch nicht kennt oder eine andere Software zur Analyse von PCAPs nutzt, sieht dort den Wahrheitsgehalt des aufgezeichneten Mediums.

Was mich da immer fasziniert, ist, dass IT-Security-Leute manchmal sagen, wir bekommen tausende Angriffe im Monat. Dadurch, dass man mit dem Internet verbunden ist, ist man ständig irgendwelchen Attacken ausgesetzt, wie auch immer die dann definiert sind, von Spam-Mails bis hin zu wirklich orchestrierten Attacken. In der OT ist es ja wahrscheinlich nicht so, dass man permanent Attacken ausgesetzt ist. Aber wenn, dann ist es wirklich kritisch, weil vermutlich jemand sehr spezifisch und gezielt angreift. Oder wie ist diese Differenzierung zu betrachten?

Jan
Das hast du schon sehr gut analysiert, Peter. Es ist in der Tat so, dass die erste Pforte zur Kundeninfrastruktur in der Regel aus der IT kommt. Klassischerweise habe ich ein IT- oder Office-Netz, das nach außen kommuniziert. Es gibt verschiedene Möglichkeiten, eine davon ist Bring Your Own Device. Das sind die Endgeräte der jeweiligen Nutzerinnen und Nutzer, die die Möglichkeit haben, ihr Smartphone für Betriebsaufgaben zu nutzen. Es gibt dann einen isolierten Bereich auf dem Smartphone, der mit der Office-IT kommuniziert. Darüber kann ich Daten austauschen und transferieren.
Parallel dazu gibt es auf einer anderen Ebene, in einer zweiten demilitarisierten Zone, die Möglichkeit, in die OT vorzudringen. Dort gibt es aber nicht viele Tore nach innen, sondern in der Regel wenige bis hin zu einem einzigen Tor. Von Zone 1 in Zone 2 zu springen, ist also nicht ohne Weiteres möglich, weil es nicht unendlich viele Pforten gibt, sondern vielleicht nur eine oder zwei. Das ist sehr klar getrennt und auch im Kontext der aktuellen Entwicklungen wichtig, wo man sich immer mehr die Verschmelzung von OT und IT wünscht.
Man muss dieses Thema aber immer mit dem Gefahrenpotenzial abwägen. Macht es wirklich Sinn, beide Infrastrukturen so zu verheiraten, dass ich die vorhin erwähnten vielen Pforten auch für die OT öffne? Denn damit schaffe ich zusätzliche Angriffsvektoren. Ein physikalisches Beispiel wäre wieder das Smartphone. Das Smartphone ist ein Einfallstor. Wenn ich es aus der IT in die OT „hineinschleppe“, wird es dort noch gefährlicher, als wenn ich einen getrennten Tunnel habe, in dem ich mich aus der OT über die IT nach außen bewege. Eine klare Trennung ist immer ein zusätzlicher Brandabschnitt, eine zusätzliche Schutzvorrichtung, von der ich profitiere. Entscheide ich mich dagegen, öffne ich mich automatisch mehreren Gefahren.

Ich kann mir gut vorstellen, dass es da eine ständige Abwägung gibt. Auf der einen Seite will ich schneller digitalisieren und Daten nutzen, diese typische IT/OT-Konvergenz leben und IT-Fähigkeiten für den Shopfloor und die OT erschließen. Auf der anderen Seite stehen genau diese Gefahren, die gegen eine zu enge Verzahnung sprechen.

Jan

Genau auf diesen Punkt würde ich gern eingehen, gerade weil du die Konvergenz erwähnst. Das ist besonders relevant, weil man häufig nur den Ideentransfer betrachtet. Daraus muss aber keine Verschmelzung der Infrastrukturen resultieren. Alles, was man in der IT lernt und was dort bereits einen Mehrwert generiert, erfordert nicht zwingend die Verheiratung der beiden Infrastrukturen. Man kann die Learnings aus der IT in die OT überführen. Das heißt, ich kenne Protokolle, ich kenne den Mehrwert dieser Protokolle, ich kann über die Assets definieren, welche Zugangsparameter relevant sind. So kann ich mir Schritt für Schritt eine Zero-Trust-Architektur aufbauen, wenn ich sie haben möchte, weil ich die Learnings aus der IT in die OT überführe.
Der Vorteil ist, ich lerne nicht aus der OT heraus, sondern aus der IT. Alles, was positiv ist, nehme ich mit in die OT. Damit schaffe ich Mehrwert auf beiden Seiten, ohne die Infrastrukturen zu verheiraten.

Und damit meinst du insbesondere Erkenntnisse, die aus Daten abgeleitet werden. Das heißt, ich übertrage Produktionsdaten, analysiere sie, gewinne daraus Erkenntnisse und überspiele dann die resultierenden Anpassungen, etwa Steuerungsanpassungen oder ähnliche Maßnahmen, wieder zurück.

Jan

Ganz genau.

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

Und wie geht ihr denn vor? Nehmen wir an, ein Unternehmen kommt auf euch zu. Dazwischen vielleicht noch die Frage: Welche Art von Unternehmen unterstützt ihr überhaupt, wie kategorisiert ihr eure Kunden? Und dann greifen wir eine Kategorie heraus, an der wir ein Beispiel durchspielen. Was wären Schritt eins, Schritt zwei, Schritt drei?

Jan

Genau. Die Verortung am Markt greift tatsächlich auf jedes Unternehmen, das eine operative Technologie einsetzt. Dort kann man uns verorten. Ich sage bewusst, man kann uns dort verorten, man muss das nicht. Es gibt Infrastrukturen, die sind sehr klein. Nehmen wir an, ich habe einen automatischen Greifarm, wirklich nur diesen Greifarm, und der Rest wird durch die IT gesteuert. Das wäre ein operatives Netz, aber eben nur anhand eines einzelnen Greifarms. Da ist es nicht unbedingt relevant, ihn besonders zu schützen, weil dieser Greifarm vielleicht nur den Kaffee hält.
Sprechen wir aber von einer großen Infrastruktur, zum Beispiel von einem Fertigungsunternehmen oder einem großen Logistikunternehmen, das seine Strukturen darauf ausgelegt hat, dass mehrere Roboter Pakete aus einem großen Hochregallager holen und in den Versand bringen, dann habe ich eine Roboterstruktur, also eine operative Technologie, die den Bedarf bündelt und kanalisiert, der aus der Kundenanfrage resultiert. Im Hintergrund passiert Folgendes: Pakete werden sortiert, gepackt und irgendwann zum Kunden transportiert. Dort habe ich ein operatives Netz. In einem solchen Umfeld kann man uns mit verorten.
Das heißt, in jedem Umfeld, in dem es operative Technologien gibt, könnte man mit Rhebo ins Gespräch gehen, sofern man in der Abwägung feststellt, dass eine relativ große und gefährliche Infrastruktur vorhanden ist, die geschützt werden muss, weil dort, salopp gesagt, viele Millionen daran hängen, die es kosten würde, wenn ein komplettes Lager für Tage, Wochen, Monate oder gar Jahre stillsteht. Das wäre fatal. Das eine oder andere Unternehmen erkennt sich darin wieder und sagt: Dann muss ich doch mal mit Rhebo sprechen.
Genauso greifen wir in kritischen Infrastrukturen, also bei allem, was wir als Energielieferanten kennen. Wir zu Hause wissen, dass irgendjemand dafür sorgt, dass unser Licht leuchtet und wir Strom haben. Auch dort kann man uns verorten. Das sind die klassischen Einsatzgebiete von uns.
Und um deine Frage zu beantworten, wie läuft das dann ab? Man kontaktiert uns und sagt: Ich habe Interesse an einem Rhebo Produkt. Dann ist jemand aus meinem Team oder ich selbst dafür verantwortlich, dass man das Produkt kennenlernt. Was können wir damit tun?
Anschließend kann man sich entscheiden. Wir empfehlen immer, über ein Assessment die Infrastruktur kennenzulernen, sodass man erste Handlungsschritte ableiten kann. Was müsste ich nach diesem Assessment tun und ist die Software von Rhebo tatsächlich die richtige für mich? Das bedeutet gleichzeitig: Nur weil ich dieses Assessment mit Rhebo mache und meine Infrastruktur komplett durchleuchte, bindet mich Rhebo nicht automatisch. Wir sagen trotz dieses Assessments und der Ergebnisse, dass man sich immer noch für eine andere Software entscheiden oder die bestehenden Strukturen beibehalten kann. Aber mit diesem Assessment habe ich einmal die Prüfung, ob ich tatsächlich gewappnet bin oder ob es noch Einfallstore gibt für jemanden, der meine Infrastruktur kompromittieren könnte.

Hast du da ein paar Beispiele, vielleicht mal aus dem Nähkästchen geplaudert, was bei so einem Durchleuchten auffällt?

Jan

Wie ich vorhin erwähnt habe, man hat meistens schon eine etablierte Infrastruktur und in der OT sprechen wir dann von Brownfield. Das ist der Gegenvergleich zu Greenfield. Greenfield, nur um es kurz zu beleuchten, bedeutet, ich habe eine Infrastruktur, die es noch nicht gibt. Hier kann ich alles komplett neu aufbauen. Deshalb das schöne Bild vom Greenfield, wie auf einem frisch angelegten Hockeyrasen.

Ganz neu gebaut.

Jan

Genau. Und Brownfield ist es in der OT, wenn ich auf einer vorhandenen Infrastruktur aufsetze. Es gibt bereits Kommunikationsprofile, entweder veraltete Protokolle oder man nutzt bekannte IT-Protokolle. Beispielsweise nutze ich eine Software, die über HTTP im Browser aufgerufen wird und nicht über HTTPS. Die Kommunikation ist also nicht abgesichert.
Wie funktioniert unsere Software? Man schließt unser System an und es sammelt alle Daten, jede Netzwerkkommunikation, die zwischen Endpunkten auftritt. Das bedeutet, wenn unsere Software zum ersten Mal implementiert wird, ist zunächst alles eine potenzielle Gefahr. Danach setzen wir uns zusammen und leiten anhand vordefinierter Metriken in der Software ab, was besonders kritisch ist. Wir sehen zum Beispiel eine Kommunikation zwischen zwei Endgeräten oder zwei operativen Technologien, die miteinander und nach außen sprechen.
Da kann es passieren, dass es ein Asset gibt, das schlicht vergessen wurde. Daran hängt jetzt ein moderner Raspberry Pi, der einen Server öffnet und IP-Adressen an neue Endgeräte verteilt. Über diese Endgeräte wird dann die Kommunikation nach außen realisiert. Das bedeutet, ich umgehe alle Schutzmaßnahmen von der IT zur OT und stelle eine zusätzliche Kommunikationsplattform bereit, weil zum Beispiel nicht verboten wurde, einen DHCP-Server aufzubauen. Das ist gefährlich, denn ich habe eine Kommunikation, die nicht nur mein Unternehmen verlässt, sondern auch den deutschen Raum.
Wir haben es schon erlebt, dass es Kommunikation ins Ausland gibt, weit entfernt, und zwar nicht nur in kleinen Datenmengen, sondern megabyteweise. Jeder, der mit Textdokumenten arbeitet, weiß, wie schnell man hohe Datenmengen erreicht. Das ist sehr viel Information, die ein Unternehmen verlassen kann. In solchen Situationen gehen wir sofort rein und sagen noch während der Analyse: Wir müssen jetzt sofort mit jemandem sprechen, der verantwortlich ist. Ist Gefahr im Verzug? Es gibt Kommunikation ins Ausland, ist sie legitim oder nicht?
Genau das tun wir während des Kennenlernens. Wir prüfen, ob unser System weiter Daten sammelt, ob es schon sehr viele Daten sind, bei denen wir kurzfristig unterbrechen und ins Gespräch gehen sollten, oder ob uns die Gegenseite sagt: Das passt, wir nehmen uns danach Zeit, schließen uns einen Tag ein und werten alles gemeinsam aus. Nach dem vereinbarten Zeitraum schauen wir auf unser System. Was haben wir gefunden? Unser Forensik-Team und unser Diagnose-Team sammeln alles und geben Empfehlungen.
Das heißt, wir sehen alte Protokolle, die niemand mehr aktiv verwendet. Wir sehen Kommunikationsversuche, bei denen zwar Anfragen verschickt, aber keine Antworten erhalten wurden, etwa bei bestimmten TCP/IP-Verbindungen.
Wir sehen alte Protokolle wie Profibus oder auch Modbus. Modbus ist zwar ein aktives Protokoll, wird aber in der Umgebung vielleicht gar nicht genutzt. Dann gibt es ein einzelnes Asset, das versucht, darüber eine Kommunikation aufzubauen. Oder wir sehen einen Drucker mit Netzwerkschnittstelle, den jemand vergessen hat. Dann kommt häufig die Aussage: Wir wussten gar nicht, dass der noch existiert und Netzwerkverkehr erzeugt.

Das sind die vielen kleinen Dinge. Leider gibt es auch die größeren, etwa ein Raspberry Pi, der irgendwo sehr versteckt hängt und zum ersten Mal auffällt. Was wir ebenfalls sehen, sind veraltete Softwarestände. Ich habe Komponenten, die ich von einem großen Hersteller zum Netzwerkschutz erworben habe, betreibe sie aber mit einer Software von 2011, obwohl die aktuelle Version von 2025 verfügbar ist. Dann sagen wir: Bitte sofort aktualisieren. Wir geben dazu auch konkrete Hinweise, wo man die Software beim Hersteller aktualisieren kann, inklusive Link.
Das sind diese charmanten Aspekte eines Reports, der am Anfang wahnsinnig simpel wirkt, aber durch die vielen Seiten sehr verwertbare Informationen enthält.

Ja, das ist allgemein bekannt, dass verschleppte Updates eines der größten Probleme im Bereich Cybersecurity sind. Das macht auf jeden Fall Sinn. Das wäre also die erste Phase, das Durchleuchten und der Report, der auf Schwachstellen hinweist. Wie geht es dann bei euch in der Regel weiter?

Jan

Genau. Dann stellen wir die wichtige Frage, ob Rhebo und unsere Software das sind, was überzeugt und gefällt, und wie es weitergehen kann. Wir lassen die bereits verheiratete Infrastruktur, also unsere Appliance oder Software, beim Kunden und sie wird in den aktiven Betrieb überführt. Eigentlich ist sie bereits im aktiven Betrieb, denn das System erkennt schon Anomalien. Aber das Unternehmen muss für sich entscheiden: Will ich das so beibehalten, möchte ich dieses passive System dauerhaft einsetzen oder nutze ich nur den Report und schicke Hardware und Software zurück?
Der nächste Schritt wäre die Überführung in den regulären Betrieb. Ab dann bieten wir an, durch unser Team zu unterstützen. Denn wenn man in der Cybersecurity etwas gelernt hat, dann, dass es zwar Teams und Zuständigkeiten gibt, aber nicht immer Forensik- und Diagnosespezialisten. Und auf irgendetwas muss ich zurückgreifen. Der Arbeitsmarkt zeigt leider, dass es ein hohes Maß an Bedarf gibt, aber nur begrenzte verfügbare Ressourcen. Genau dort liefern wir die Option, auf den Service von Rhebo zurückzugreifen, unsere Kolleginnen und Kollegen anzurufen und Unterstützung anzufordern.

Sehr gut. Du hattest gerade die passive Software erwähnt. Das ist auch mein Verständnis, dass gerade OT-Security eher passiv lauschen muss und nicht im kritischen Pfad liegen darf, um keine Verzögerungen zu verursachen. Wie funktioniert das genau und welche Auswirkungen oder besser gesagt Nicht-Auswirkungen hat das?

Jan

Ganz einfach ausgedrückt bedeutet ein passives System, dass ich keinen zusätzlichen Network Traffic verursache, also keine zusätzliche Last. Genau das kann in kritischen Infrastrukturen sehr gefährlich sein. Zusätzliche Last kann zu irreparablen Schäden führen, weil Kommunikation nicht stattfinden kann oder stark verzögert wird. Dann sind wir wieder beim Hochregallager oder bei Robotern. Ich muss Roboter in kurzen Zeitintervallen ansprechen, ich muss Befehle sehr genau und in enger Taktung gegenprüfen können. Wenn ich zusätzlichen Traffic generiere, erzeuge ich auch zusätzliche Latenzen, also Antwortzeiten zwischen Senden und Empfangen.
Genau das macht ein passives System nicht. Das passive System schaut nur auf den Datenverkehr und sagt: Das ist das, was ich sehe, aber ich greife nicht ein. So arbeiten unsere Primärinstanz, unsere Controller-Instanz und unsere Sensorik. Der Name sagt es: Die Sensorik beobachtet. Sie ist rückwirkungsfrei, der laufende Betrieb wird nicht gestört, die Pakete werden nur mitgeschnitten und ausgewertet.
Wenn ich einen weit entfernten Ort habe, sprechen wir von Flottenmanagement. Ich habe eine große Flotte, etwa Batteriespeicher oder autonome Fahrzeuge. Alles, was dort Kommunikation verursacht, kann ich vor Ort nicht mit klassischer Netzwerkinfrastruktur überwachen, weil keine Instanz mitläuft, die permanent draufschaut. Das ist nicht Teil meines lokalen on-premise Netzes, sondern off-prem, es kommuniziert vielleicht über 5G oder LTE.
In solchen Fällen arbeiten wir mit Sensorik, mit einem Agenten, einem zusätzlichen Stück Software. So entsteht die Möglichkeit, ein Asset im Feld zu prüfen, das sich frei bewegt. Die Daten, die dort aufgenommen werden, werden gesammelt, gebündelt und an unsere Primärinstanz geschickt. Entweder schalte ich einen Broker dazwischen, der das Handling übernimmt, damit nicht gleichzeitig eine enorme Anzahl an Anfragen vom gleichen System eintrifft. Der Broker paketiert die Daten zum richtigen Zeitpunkt, sendet sie an den Observer, also an eine Auswerteinstanz, die nach Kundenwunsch gestaltet sein kann. Dort findet dann die Analyse statt.
Ein Beispiel wäre: Ist mein Akku noch ausreichend geladen oder muss ich zur Ladesäule? Oder ist eines meiner virtuellen Kraftwerke im Feld, etwa von einem Photovoltaikanbieter, gerade kompromittiert oder bricht weg, weil ein kritischer Ladestand erreicht ist? Die Batterie versorgt den Haushalt nicht mehr, obwohl es ein sehr sonniger Tag ist und eigentlich Energie gewonnen werden müsste. Das ist auffällig. Das sind Situationen, in die man hineinschauen und ein Gefühl für die eigenen Daten entwickeln muss.

Ihr habt sozusagen dort, wo eine Fabrik ist, die Möglichkeit, mit der entsprechenden Hardware die Infrastruktur zu lesen und zu beobachten. Beim Flottenmanagement, also alles, was im Feld unterwegs ist, da pingt ihr dann die verschiedenen Flottenbestandteile, ob das Kraftwerke, Solarpanels oder Autos sind, um jeweils den Status zu prüfen, ob alles in Ordnung ist.

Jan

Fast umgekehrt. Wir würden dort jemanden platzieren, also entweder einen Agenten oder ein Stück unserer Software, das zurückpingt und sagt: Hier passiert etwas, hier müssen wir intervenieren. Und tatsächlich nicht auf die Panels, sondern auf die Umspannrichter. Das Interessante ist nicht das einzelne Panel auf dem Dach, ob das funktioniert. Es gibt mittlerweile fortgeschrittene Technologien, da ist das einzelne Panel nicht mehr so relevant. Spannend ist der Wechselrichter. Den muss ich schützen, der muss funktionieren. Der hängt dann auch an einem Smart Meter. Und wenn man sich die Trends in Deutschland anschaut: Smart Meter waren früher vielleicht nicht so relevant, aber seit es immer stärker in Richtung erneuerbare Energien geht, sieht man, dass es gar nicht so verkehrt ist, wenn man seinen Smart Meter noch einmal gegenprüfen kann. Welche Daten kommen vom Wechselrichter beim Zähler an?

Okay, lass mich noch einmal einen Schritt zurückgehen, zur Thematik Trends für das Jahr 2025 oder auch 2026 nach vorne geblickt. Was passiert gerade im OT-Cybersecurity Markt?

Jan

Was passiert, das hatte ich vorhin schon erwähnt, ist zum einen, dass immer mehr Angriffe wahrgenommen werden. Nehmen wir große Hersteller von Fahrzeugen oder mobilen Maschinen, die sich auf unseren Straßen bewegen. Dort gibt es Timelines, die von Angreifern genannt werden. Sie sagen: Wir haben eure Daten verschlüsselt, ihr habt keinen Zugriff mehr. Ihr habt bis Ende der Woche Zeit, sonst bezahlt ihr mit den Daten eurer Kunden. Was wir auch sehen, ist: Das Bewusstsein ist da, dass man Cybersecurity-Software und -Service braucht. Aber die Kaufentscheidung ist oft noch nicht getroffen.
Das liegt zum einen daran, dass es eine große Streuwirkung durch viele Hersteller gibt. Die meisten bieten Cybersecurity für IT und OT an, viele davon aus dem Ausland. Deshalb ist ein großes Trendthema am Markt: Wir wollen Security und speziell Cybersecurity aus Deutschland. Man möchte das Bewusstsein im Land halten und die Security Lösung aus dem eigenen Land beziehen. Gleichzeitig vergleicht man aber alle Hersteller, die es global gibt, und hofft, dass all die neuen Gesetzgebungen, die gerade formuliert werden, schon greifen und einen schützen, was sie allein gar nicht können.
Nehmen wir Cybersecurity in Richtung NIS2. Dort gibt es Regelungen, die festlegen, welche Vorsichtsmaßnahmen ein Lieferant getroffen haben muss. Vergleiche ich das mit dem IT-Sicherheitsgesetz 2.0, stellt sich die Frage: Wo ist mein Hoster platziert, sind meine Daten tatsächlich in Deutschland oder in Europa? Dann kommt ein Hyperscaler wie Microsoft und sagt: Wir können nicht garantieren, dass 100 Prozent der Daten nur in Deutschland oder in der EU verarbeitet werden. Man hat also den Wunsch und das Trendthema Cybersecurity, das Gefühl, wir müssen unbedingt etwas tun. Aber die Realität ist: Um Vergleichbarkeit herzustellen, geben wir unsere Daten doch wieder in fremde Hände und wissen nicht genau, wo sie liegen. Also ein großer Trend ist Security.

Natürlich spielen auch die EU-Richtlinien wie NIS2 und der Cyber Resilience Act sowie deren Weiterentwicklung hinein. Ich finde das im Grunde positiv, denn wenn man auf die aktuelle politische Weltlage schaut, ist das mit möglichen staatlichen Akteuren, die aktiv werden könnten, nichts, was man verschlafen darf, insbesondere in kritischen Infrastrukturen.

Jan

Gerade in der Industrie wird das Thema kritische Infrastruktur trotzdem oft vernachlässigt. Das Bewusstsein ist da, jeder kann sich damit identifizieren, dass wir etwas tun müssen. Wir haben diese Infrastrukturen lange in Ruhe gelassen und historisch wachsen lassen. Jetzt wird es Zeit, sie zu schützen und zu härten. Auf der anderen Seite wünscht man sich, das mit Lösungen aus dem eigenen Land zu tun, unterstützt die vorhandenen Firmen aber nicht immer gezielt, sondern sagt: Wir müssen etwas tun, lassen uns aber alle Optionen offen, wie wir es tun. Bei uns hätte man sich dann schnell entschieden. Wir haben eine deutsche Lösung, die bei uns entwickelt wird, und das aus dem wunderschönen Leipzig, wo wir auch sehr gute Entwickler haben.

Top. Wie passiert denn so ein Angriff? Was machen die Angreifer da und wie gehen sie vor? Wie hebeln sie vielleicht vorhandene Security-Maßnahmen aus?

Jan

Da hatten wir ein gutes Beispiel. Wir nennen es einfach Social Engineering, ohne den Kundennamen zu nennen. Es ist tatsächlich jemand über sein LinkedIn-Profil von einer Recruiterin angesprochen worden, die ein sehr angenehmes Auftreten hatte und sehr offen wirkte, als sei sie an der Person interessiert. Im Subtext war sie aber vor allem am Unternehmen interessiert. So wurde nach und nach eine Beziehung aufgebaut, bis es den Moment gab, an dem man die Daten für ein potenzielles Bewerbungsgespräch abgleichen wollte. Dazu wurde die Person aufgefordert, ein Dokument herunterzuladen und dort noch einmal aktuelle Informationen über sich als Person zu hinterlegen, natürlich mit gegenseitigem Einverständnis.
Man sollte dieses Dokument herunterladen mit dem Hinweis, dass es aktive Steuerungskomponenten innerhalb des Dokuments gibt und man deshalb die Kommunikation zulassen müsse, weil es sonst nicht ordnungsgemäß funktioniere. Das wurde gemacht und im Hintergrund hat sich ein Agent installiert, der in der Lage war, Kommunikationsplattformen zu öffnen, also ein Nutzerprofil zu erstellen und auf Basis dieses kompromittierten Profils Dienste bereitzustellen und nach außen zu transportieren. So wird nach und nach Schlupflöchern auf dem System gesucht, über das ich gerade herunterlade, in diesem Fall leider ein Unternehmenssystem, das sehr weit hinten in der Infrastruktur hängt. Darüber wurde es dann möglich, Kommunikation nach außen zu realisieren.
Genau das fällt bei uns auf. Dieses System, nennen wir es jetzt einfach Notebook oder Desktop PC, verhält sich zwar in sich selbst schon atypisch, aber das fällt nicht auf, solange es nicht nach außen kommuniziert. Für uns wird es relevant, sobald es anfängt nach außen zu kommunizieren, also wenn es den eigenen Schreibtisch verlässt und versucht, andere Schreibtische zu erreichen. Genau dann sehen wir das. Dann schlägt unsere Anomaliedetektion sauber an und gibt den Hinweis: Hier verhält sich jemand sehr atypisch, bitte sofort etwas unternehmen.

Das macht es sehr anschaulich und auch ein bisschen beängstigend. Denn ein Dokument herunterzuladen, insbesondere wenn man denkt, man sei mit einer legitimen Person im Austausch, kann sehr schnell passieren. Da ist Aufklärung extrem wichtig, also über solche Themen zu sprechen. Gerade im OT-Bereich, denn wenn in der IT das Büro mal eine Zeit lang nicht funktioniert, kann man das je nach Umfeld noch eher verkraften. Wenn aber wirklich die Produktion stillsteht, vielleicht über einen längeren Zeitraum, dann sicher nicht mehr.

Jan

In der Tat.

[27:46] Übertragbarkeit, Skalierung und nächste Schritte – So könnt ihr diesen Use Case nutzen

Wie entwickelt sich das Ganze aus deiner Sicht? Woran arbeitet ihr, welche Lösungen entstehen gerade? Wenn man an KI-Agents denkt, die mit generativer KI arbeiten, wird das ja immer komplexer und umfangreicher, was möglich ist, sei es Social Engineering mit personalisierten E-Mails oder neue Angriffsvektoren. Kannst du dazu etwas erzählen?

Jan

Ja. In der Tat nenne ich es Agent, aber bei uns ist es eigentlich kein klassischer Agent. Ein Agent ist normalerweise eine relativ große Instanz, die sehr viele Möglichkeiten mitbringt, auch für Verwaltung und Steuerung. Bei uns kann man sich das eher so vorstellen: Ich nenne es Agent, damit es greifbarer wird, aber im Kern passiert nichts anderes, als dass Daten gesammelt werden. Alles, was auf dem jeweiligen Asset passiert, wird aufgenommen, durchleuchtet, gebündelt und an die primäre Instanz gesendet. Es ist also kein Agent, wie man ihn von Anti-Viren-Software kennt.
Genau dort setzt auch unser Trend im Zusammenhang mit KI an. Wenn man genauer hinschaut, sieht man oft nur die Bequemlichkeit: Was kann mir KI oder AI bringen, um meinen Tag zu erleichtern? Da geht es um Datenauswertung. In der Cybersecurity ist das aber der Gegenpart. Eine KI kann auch gefährlich werden, wenn sie falsch angelernt wird. Und es gibt keine Schablone. Man kann nicht einfach sagen: KI, lerne meine Infrastruktur kennen, und danach rolle ich das Modell auf die nächste Stadt aus und dort funktioniert es genauso. Das ist nicht der Fall, weil dort andere Protokolle gesprochen werden und ein anderer Bedarf existiert.
Diese bedarfsgerechte KI-Modellierung ist aktuell nicht so möglich, dass ich sage: Ich schablonisiere. Nehmen wir einen großen Flughafen mit 20 Gates. Ich kann nicht für jedes Gate exakt das gleiche Szenario aufsetzen und dort die gleiche KI einsetzen, um Auswertungen zu fahren und Optimierungen einzuleiten. Es gibt zu viele unterschiedliche Strukturen: das Sicherheitsnetz mit Kameras in einem separaten Netz, damit sie nicht kompromittiert werden, das Zugangsnetz mit Badge-Readern und NFC, möglicherweise wieder ein getrenntes Netz. Wie soll ich all das mit einer einheitlichen KI schützen? Unsere Antwort ist: Bitte nicht einfach pauschal mit KI anlernen.
Wir haben dazu Studien in Zusammenarbeit mit anderen Unternehmen und Institutionen veröffentlicht. Die Frage war: Bringt KI aktuell wirklich einen Mehrwert im operativen Einsatz in der Cybersecurity? Unser Stand heute ist: Nein, noch nicht. So intelligent ist sie dann doch nicht. Sie vergleicht Informationen, verarbeitet sie und liefert Interpretationen. Aber eine echte Intelligenz steckt nicht dahinter. Es gibt kein Bewusstsein dieser Software, das eigenständig ableitet, ob etwas wirklich eine Gefahr ist. Sie arbeitet mit Schemata, Mustern und Algorithmen.
Das menschliche Bewusstsein sagt dagegen: Für mich ist das eine Gefahr. Auch wenn sich ein Asset so verhält, dass es zum ersten Mal ein neues Protokoll spricht und das auf den ersten Blick nicht gefährlich aussieht, kann es trotzdem kritisch sein. Es ist ein neues Asset, es ist auffällig. Ich bewerte das als Mensch anders als eine künstliche Intelligenz. Sie hat keine Emotionen und keine Gefühle.

Ja, genau. Und damit sind wir bei einem wichtigen Punkt. Ich differenziere auch gerne zwischen klassischer KI, bei der man Algorithmen gezielt für bestimmte Anwendungsfälle antrainiert, und generativer KI. Gerade im Cybersecurity Umfeld ist bisher eher die klassische KI getestet und eingesetzt worden, weil es dort um Mustererkennung geht. Man muss Muster trainieren und versuchen, dass diese klassische KI bei Anomalien auslöst. Das ist extrem schwierig, weil man sehr viele Daten und atypische Muster braucht, wie du vorhin beschrieben hast, um ein Modell erfolgreich zu trainieren. Das ist nicht einfach. Generative KI hat dagegen ganz andere Anwendungsfälle. Sie ist für solche komplexen Mustererkennungen gar nicht gedacht. Da arbeitet man mit Prompts, mit Spracheingabe, mit Text.
Also da gebe ich dir recht. Wenn viel über KI und ihre Möglichkeiten gesprochen wird, ist gerade die Mustererkennung in der Komplexität und Schnelligkeit, die dort nötig wäre, mit generativer KI überhaupt nicht leistbar.

Jan

Aber auch dort, in den Prompts, gab es schon diverse Diskussionen darüber, wie man Prompts manipulieren kann. Man darf auch nicht vergessen: Wenn eine Seite, nennen wir sie gern die gute Seite im Blue Team, dafür sorgt, die Infrastruktur zu schützen, gibt es auf der anderen Seite das Red Team, das böse Team, das die Infrastruktur gezielt attackiert. Nur weil wir eine KI einsetzen wollen, um uns zu schützen, heißt das nicht, dass die Gegenseite nicht ebenfalls eine KI oder sogar die identische KI nutzt, um uns zu kompromittieren. Das eröffnet ein neues Gefahrenpotenzial.

Da glaube ich eher daran, dass generative KI genutzt werden wird, um anzugreifen, zum Beispiel im Social Engineering. Erzähl doch bitte noch einmal kurz das Thema Red Team und Blue Team. Habt ihr das bei euch selbst, dass ihr euch beauftragen lasst, eine Firma absichtlich anzugreifen, um Schwächen aufzudecken, also so ein Red Team Ansatz?

Jan

Nicht direkt über uns. Wir wollen immer vermeiden, dass der Eindruck entsteht, alles müsse zwingend mit der Firma Rhebo gemacht werden. Wir sprechen Empfehlungen aus und nennen Firmen, mit denen wir solche Einsätze gemeinsam umsetzen. Wir haben dort auch einen bevorzugten Partner, ganz bewusst einen Partner und nicht Rhebo selbst, der uns vertritt und das Red Teaming sowie den Umfang des Red Team Einsatzes definiert. Klassisch kennt man das als Penetrationstest oder Pentest. Der Begriff klingt oft wie ein ungeliebtes Pflichtprogramm, nach dem Motto, lass uns einfach mal einen Pentest machen. Entscheidend ist aber, wie ich meinen Pentest strukturiere und in ein Red Team Szenario übersetze. Will ich aus der bestehenden Infrastruktur heraus testen, also einen internen Pentest fahren, oder gebe ich der beauftragten Firma auch juristisch den Rahmen und sage: Bitte starte den Test von außen. Wir glauben, wir sind sicher, möchten dir aber schriftlich zusichern, dass du abgesichert bist, wenn du uns attackierst und Schlupflöcher findest. Bis zu diesem Punkt darfst du gehen, danach ist Schluss. Diese Parameter legt man gemeinsam fest. Wir geben dazu Empfehlungen, führen die Tests aber nicht selbst durch. Wir sind Teil des Blue Teams, wir sind Teil des Schutzsystems, das ist unsere Rolle. Für Red Team Einsätze empfehlen wir Firmen, mit denen wir seit vielen Jahren vertrauensvoll zusammenarbeiten.

Vielen Dank, Jan. Ich fand es super interessant. Willst du zum Abschluss noch etwas sagen aus deiner Sicht? Was würdest du den Hörern gerne mitgeben, was müssen sie besonders berücksichtigen?

Jan

Besonders wichtig ist aus meiner Sicht, Markttransparenz zu schaffen, indem man die Hersteller vergleicht, die wir hier in Deutschland oder in der EU haben, und im Sinne von Datenschutz und Datensicherheit Lösungen bevorzugt, die On-Prem laufen und in meinem direkten Zugriff sind. Das ist auch das, was wir gern empfehlen. Wenn ich meine Daten in erster Instanz schon aus der Hand gebe, indem ich ein dezentrales Rechenzentrum nutze, wird es gefährlich, wenn ich mein Sicherheitssystem irgendwo hoste und es dann als gehärtet und gesichert betrachte. Denn genau darin liegt eine Gefahr. Es ist ein Einfallstor, das ich nicht selbst in der Hand habe, um es zu schützen. Ich muss mich darauf verlassen, dass es jemand anders getan hat.
Das ist das, was ich gern mitgeben möchte. Es schadet nicht, fünf Minuten in ein Gespräch zu investieren, mit Rhebo zu sprechen oder mit einem unserer Marktbegleiter, sofern er aus Deutschland kommt. Wir haben hier ein anderes Bewusstsein. Wir denken nicht so stark amerikanisch geprägt. In vielen Dingen fühlt man sich damit wohler, weil es vertraut ist. Und genau diese Vertrautheit kann man stärker nutzen. Für mich ist eigentlich nur relevant, dass man uns die Chance gibt, mehr gesehen zu werden, mehr Transparenz darüber zu schaffen, wie wir agieren. Ich sage nicht, geht bloß nicht zum Wettbewerb. Ich wünsche mir, dass man allen eine Chance gibt, die aus der EU kommen. Denn das ist es, was wir uns wünschen. Ein bisschen mehr Stärke für die Unternehmen, die hier gewachsen sind.
Das macht uns als Rhebo stark. Wir sind in Leipzig gewachsen, unsere Gründer kommen aus Leipzig und Umgebung. Das macht uns greifbar. Und das ist etwas, von dem man profitieren kann und auch sollte.

Sehr gut. Und Jan, wie kann man dich am besten erreichen, wenn die Zuhörer jetzt sagen, dass sie auf jeden Fall mit dir sprechen wollen?

Jan

Es gibt endlos viele Möglichkeiten. Am einfachsten ist LinkedIn oder unsere Homepage rhebo.com. Dort kann man uns erreichen und direkt ein Gespräch mit mir oder mit einer Kollegin oder einem Kollegen vereinbaren.

Dann bleibt mir nur zu sagen, vielen Dank und bis zum nächsten Mal.