Pressemitteilungen Rhebo

News

OT Security Made Simple | Eine Woche im Leben eines OT-Sicherheitsbeauftragten

Diesmal gibt es direkten Einblick in den Alltag eines Sicherheitsteams bei einem Verteilnetzbetreiber. Wir begrüßen Daniel Beyer (Dachgebietsleiter für Systemtechnik und OT) sowie Sebastian Miethe (Netzwerktechnik und IT Security) von Thüringer Energienetze (TEN). Die beiden OT-Sicherheitsexperten von vorderster Front erzählen, warum Sichtbarkeit über alle Netzwerke, Systeme und Schnittstellen das A und O ist, warum ein SIEM allein nichts wert ist und wie Systemtechnikteams OT-Sicherheit in ihren Alltag integrieren, ohne in Alarm Fatigue zu verfallen.

 

 

 

Hören Sie uns auf:

  

 

Transkript

Klaus Mochalski

Hallo und herzlich willkommen zu einer neuen Folge des Rhebo Podcasts. Ich sitze heute hier mit Daniel Beyer und Sebastian Miethe von Thüringer Energienetze (TEN) [Anm.: Thüringens größtem Verteilnetzbetreiber]. Herzlich willkommen!

Wir haben uns im Vorfeld abgestimmt, dass wir heute unseren Hörer:innen einfach mal berichten wollen, wie ein relativ langjähriger Kunde mit unserem System [Anm.: der OT-Angriffserkennung Rhebo Industrial Protector] umgeht, welche Erfahrungen gesammelt wurden, wie das System betrieben wird und auch wie über die Jahre die Evolution im Einsatz stattgefunden hat.

Ganz am Ende wollen wir uns auch noch anschauen, wie in Hinblick auf die aktuelle BSI-Orientierungshilfe die Umsetzung dieser Anforderungen aussieht. Aber dazu ganz am Ende. Bevor wir starten, eine kurze Vorstellung. Fangen wir bei dir an, Daniel.

Daniel Beyer

Hallo, ich bin Daniel Beyer. Ich bin Fachgebietsleiter bei der TEN für die Systemtechnik und für die OT und verantworte in meinem Anwendungsbereich das Netzleitsystem der TEN. Ich bin dafür zuständig, dass das System immer einsetzbar ist. Und obendrein bin ich auch für die IT Security zuständig. Das betreut bei mir Herr Miethe, der neben mir sitzt.

Sebastian Miethe

Ich bin noch ein relativ neuer Kollege bei der TEN und bin jetzt seit ungefähr einem Jahr und fünf Monaten dabei. Ich komme vom Background her eigentlich aus einem Elektrotechnik-Studium mit Vertiefung, aber auch Kommunikationstechnik und bin jetzt bei Daniel im Fachgebiet für Netzwerktechnik und IT Security zuständig.

Klaus Mochalski

Perfekt. Also seid ihr genau die Experten. Das finde ich auch für unsere Hörer:innen extrem wertvoll, dass nicht immer nur wir als Hersteller erzählen, wie die Erfahrungen unserer Kunden sind, sondern dass das aus erster Hand kommt.

Die TEN, die Thüringer Energienetze, ist mittlerweile seit 2019 Kunde bei Rhebo. Da haben wir mit unserem Sicherheitsaudit begonnen. Daniel, ich glaube, du warst von Anfang an dabei. Kannst du einfach mal so ein bisschen erzählen, wie so die Evolution war? Wie seid ihr dazu gekommen, 2019 unser Sicherheitsaudit [Anm.: das Rhebo Industrial Security Assessment] durchzuführen? Gab es da schon einen klaren Plan? Wie habt ihr weitergemacht? Und wie hat sich die Installation bis heute Schritt für Schritt entwickelt?

Daniel Beyer

Wir haben 2019 angefangen, das erste Sicherheitsaudit zu machen. Die Motivation für uns kam daher, dass wir ein neues Leitsystem bei uns eingeführt haben und ein Kollege und ich zusammen dieses System betreut haben. Uns wurde immer bewusster, dass die Anforderungen immer höher und größer werden, auch in der IT Sicherheit und vor allen Dingen in diesen ganzen Netzwerkgeschichten. Und da ist uns aufgefallen, dass es da ziemlich viele Sachen gibt, die wir monitoren müssten.

Daraufhin gab es eine Veranstaltung hier in Leipzig bei den Stadtwerken [von Netz Leipzig], wo ich euer System zum ersten Mal gesehen habe. Ich fand das eigentlich relativ innovativ, bin dann wieder zurückgefahren nach der Veranstaltung und habe mit meinem Kollegen darüber gesprochen. Er meinte, wir können ja mal Tests machen.

Und daraufhin gab's dann das erste Sicherheitsaudit. Danach wurde die erste Instanz [des OT-Monitoring mit Anomalieerkennung Rhebo Industrial Protector] bei uns aufgebaut, wo wir uns vorrangig auf das Leitsystem fokussierten. Damit kam dann alles zum Laufen. Und ja, seitdem sind wir dabei und bauen das immer weiter aus.

Klaus Mochalski

Vielleicht ganz kurz. Zum Hintergrund: Unser Sicherheitsaudit ist bei Neukunden immer der erste Schritt. Und erst anhand der Ergebnisse entscheiden wir dann gemeinsam mit dem Kunden, wie das richtige Einsatzmittel genau aussieht. Tatsächlich ist das Standardeinsatz-Szenario im ersten Schritt, dass wir die Kommunikation vom und zum Leitsystem überwachen. Das deckt sich also mit den Erfahrungen.

Und tatsächlich, weil du von Netz Leipzig sprachst, ist das einer unserer allerersten Kunden, die das System mittlerweile seit 2015 im Einsatz haben. Umso schöner ist es natürlich auch zu sehen, wie das immer mehr inspiriert.

Beim Sicherheitsaudit kommen ja manchmal Dinge zu Tage, die für die Betreiber der Infrastrukturen nicht immer nur schön sind. Wie war das denn bei euch?

Daniel Beyer

Ich kann mich noch sehr gut daran erinnern. Wir haben das damals aufgebaut und haben es drei Monate lang laufen lassen. Für uns war ein sehr gutes Ergebnis [des Audits], dass wir unsere Infrastruktur erstmal auch gut strukturiert gesehen haben. Und dabei sind natürlich auch einige Schwachstellen zu Tage getreten, die uns nicht so bewusst waren. Aber wir konnten mit den Kollegen, die das durchgeführt haben, auch diese beseitigen und wussten im Nachhinein auch, worauf wir uns fokussieren müssen und was Rhebo eigentlich kann.

Klaus Mochalski

Ja, wir haben mit der Zeit auch immer mehr gelernt, mit diesen heiklen Ergebnissen umzugehen. Das wird von unserer Seite häufig durch Techniker präsentiert. Am Anfang war das eher so, dass das sehr direkt rüberkam, und unsere Kunden haben dann fast so etwas wie eine psychologische Schulung durchgemacht. Klar, wir haben häufig die Situation, dass wir die Ergebnisse vor einem Kreis von Technikern präsentieren. Aber manchmal ist dann eben doch der Fachbereichsleiter oder der Geschäftsführer mit in der Veranstaltung [dem Abschlussworkshop des Audits], und dann kommen diese Schwachstellen zutage. Das ist natürlich nicht immer eine schöne Situation.

Aber das Gute ist, dass wir dann gemeinsam daran arbeiten und diese Dinge verbessern können. Das ganz Wichtige ist dieser kontinuierliche Verbesserungsprozess, der dann stattfindet. Wie waren denn eure nächsten Schritte? Wann habt ihr euch dann entschieden, weitere Anlagen in die Überwachung mit aufzunehmen, und welche Anlagen sind das heute?

Daniel Beyer

Das ging dann so weiter, dass wir das System gut am Laufen hatten und uns ein Bild machen konnten, was bei uns Richtung Leitsystem läuft. Also, wir haben die ganzen Außenkanten quasi eingefangen und konnten sehen, was ins Leitsystem reinkommt. Dann kam natürlich die nächste Fragestellung: Was ist denn in unseren weiteren Netzbereichen? Daraufhin haben wir noch andere Schnittstellen oder Netzübergänge mit neuen Instanzen ans Rhebo [-System] gekoppelt und das immer weiter ausgebaut. So lief das bei uns. Letztendlich sind wir bis in die Umspannwerke reingegangen. Da kann nachher Sebastian etwas sagen.

Klaus Mochalski

Die Umspannwerke?

Daniel Beyer

Genau in die Umspannwerke. Wir versuchen jetzt, den ganzen Weg abzudecken. Zum Beispiel vom Umspannwerk bis zu uns ins Leitsystem rein. Und die andere Richtung, also Richtung Büro-Netzwerk, wird ebenfalls überwacht. So haben wir alle Schnittstellen im Griff.

Klaus Mochalski

Das ist tatsächlich ein Trend, den wir auch beobachten, dass die Umspannwerke in die Überwachung einbezogen werden. Denn viele Umspannwerke werden ja aktuell digitalisiert. Neue Komponenten werden eingebaut, die fachlich IEC 61850 sprechen. Das heißt, da gibt es neue Möglichkeiten nicht nur der Automatisierung, sondern natürlich auch neue Möglichkeiten der Überwachung. Sebastian kannst du ein bisschen was dazu erzählen, was ihr da aktuell macht und was ihr da beobachtet?

Sebastian Miethe

Also wir haben Rhebo eigentlich an vier Stellen oder vier Netzsegmenten hauptsächlich im Einsatz. Das ist einmal an einer Außenkante – nicht ins Internet, aber zum Netz unseres Mutterkonzerns. Wir wussten auch nicht, was von da alles so zu uns rüber kommt. Das ist auch interessant. Dann einmal die Netzwerkanbindung, das [IEC]104 Protokoll. Und die neuesten zwei sind eigentlich ein Service LAN, wo Drittanbieter-Apps wie Telefonie drüber laufen. 

Daniel Beyer

Verwaltungsnetze. 

Sebastian Miethe

Genau, aber auch schon bis ins Umspannwerk. Und ganz neu ist, dass wir versuchen, in allen Instanzen und digitalisierten Umspannwerken einen Rhebo-Sensor zu verbauen.

Klaus Mochalski

Diese gemeinsame Reise ist äußerst spannend. Weil wir auch den Trend beobachten, dass die Infrastrukturen, die ihr betreibt, immer verteilter werden. Das sind immer mehr verteilte Komponenten, die aber digital angeschlossen sind. Bis hin zu Dingen wie Batteriespeicher, Ladestationen. Da muss man dann auch schauen, wer am Ende der Betreiber ist.

Aber solche Anlagen kommen dazu in großer Zahl. Und da ist es für uns wichtig, dann auch eine Lösung bieten zu können, dass man am Ende auch solche Systeme mit einfachen Mitteln, auch mit überschaubarem Aufwand überwachen kann. 

Aufwand ist das perfekte Stichwort, denn das ist eine Frage, die wir sehr häufig gestellt bekommen. Wie viel Aufwand verwendet ihr aktuell im Schnitt, um das Angriffserkennungssystem – früher haben wir es Anomalieerkennungssystem genannt – zu betreiben? Viele unserer Neukunden haben tatsächlich Angst vor dem betrieblichen Aufwand. Insbesondere vor den sogenannten False Positives, das heißt, Alarme, die nicht wirklich relevant sind, aus Betriebssicht. Wie ist eure Erfahrung da in den letzten Jahren?

Sebastian Miethe

Also, ich kann jetzt nur für die letzten anderthalb Jahre sprechen. Möchtest du anfangen, Daniel?

Daniel Beyer

Ja, ich kann auch kurz anfangen. Also am Anfang war es so, dass wir relativ viel Zeit darauf verwendet haben. Aber mit der Zeit, wie du schon gesagt hast, lernt das System halt mit. Und dann haben wir auch mehr Erfahrung gesammelt, wussten, worauf wir achten müssen. Deswegen ging der Aufwand auch wieder zurück. Wir wussten zudem, mit den Fehlern [Anm.: false positive Meldungen] umzugehen. Man konnte die dann [über die Monitoringfunktion für einzelne Events] beobachten usw. und konnte das auch besser einschätzen. Bei einer Instanz haben wir damals am Anfang täglich eine halbe Stunde drauf geguckt und dann letztendlich eine Stunde die Woche. Als dann mehr dazukam, da weiß Sebastian mehr, wie da jetzt der Stand ist.

Sebastian Miethe

Also vielleicht zum aktuellen Modus. Wir haben quasi 1 bis 2 Leute, die da täglich, also mindestens jeden Abend draufgucken. Ich versuche auch, jeden Tag eine halbe Stunde rein zu gucken. Wir haben das Rhebo-System aber auch so eingestellt, dass wir uns immer Benachrichtigungen schicken lassen von Dingen, wo wir sagen, die sind uns wirklich wichtig. Das sind in der Regel hauptsächlich die sicherheitsrelevanten Sachen. Und unser Ziel ist es auch, das Rhebo-System mit in unsere SIEM-Systeme [Anm.: SIEM steht für Security Information & Event Management] zu integrieren, damit wir auch da eine Verbindung hinkriegen und eine bessere Überwachung.

Klaus Mochalski

Das wäre jetzt meine nächste Frage. Email-Benachrichtigung klingt jetzt noch nicht wie die finale Lösung.

Sebastian Miethe

Richtig.

Klaus Mochalski

Das ist auch etwas, was wir häufig als Anforderung bekommen. Welche Schnittstellen zu einem SIEM-System zur Verfügung stehen. Da ist unsere Antwort immer erstmal pauschal “potenziell jede oder wir unterstützen jedes SIEM” [Anm.: Rhebo Industrial Protector ist bereits als App für IBM QRadar verfügbar und bietet grundsätzlich Standardschnittstellen zur Integration in andere SIEM-Systeme].

Und aus unserer Sicht ist das Problem gar nicht so sehr die technische Schnittstelle, sondern die Vereinbarung zwischen den häufig auch unterschiedlichen Teams, die das SIEM vielleicht auch in einem SOC, in einem Security Operations Center, betreiben, und den Betreibern des Angriffserkennungssystem. Da ist man dann erstmal flexibel. Es können potenziell sehr viele Daten zur Verfügung gestellt werden.

Die Frage ist auch immer, ob die empfangende Stelle damit etwas anfangen kann. Wir können aber auch selektive Daten zur Verfügung stellen. Habt ihr da schon eine Vorstellung, wie das bei euch sein wird? Also wer wird die Daten beobachten? Wird es eine Stelle geben oder wird es immer mehrere Stellen geben, die diese Daten verarbeiten?

Sebastian Miethe

Ich denke, es werden erstmal immer mehrere sein. Wir werden auch bei dem Modus bleiben, dass man sich immer noch auf der Weboberfläche von Rhebo Industrial Protector eingeloggt, um sich den Protokollverlauf anzugucken. Aber ja, das Rhebo-System wird dann auf jeden Fall die Meldungen direkt an ein SIEM-System schicken.

Daniel Beyer

Und E-Mail müssen wir leider aufgrund unserer internen Prozesse noch mit betreiben. Es wird wahrscheinlich dann irgendwann auslaufen, wenn das SIEM richtig läuft. Aber bis dato ist es noch so, weil wir so gewachsen sind. Die ganzen Infrastrukturen bei Energienetzbetreibern sind halt auch viel E-Mail-basiert. Das ist halt einfach unsere Erfahrung.

Klaus Mochalski

Du sagtest vorhin eine Stunde pro Woche. Das ist ja tatsächlich ein sehr überschaubarer Aufwand, wenn man sich mal ausrechnet, was ein Vorfall bei einem Netzbetreiber, wie ihr einer seid, kosten würde. Nicht nur, was die rein monetären Kosten sind, sondern auch die Auswirkungen am Ende für die Kunden, für die Netzversorgung. Dieses Meldesystem, das interessiert mich noch. Mit wie vielen Alarmen habt ihr es denn da zu tun bei der aktuellen Einstellung? Und landen die Meldungen bei euch? Oder habt ihr auch so ein 24/7 Rotationsprinzip?

Sebastian Miethe

Die E-Mail-Benachrichtigungen schwanken in der Anzahl. Aber es sind vielleicht so bis zu zehn am Tag.

Klaus Mochalski

Bearbeitet ihr die sofort oder sichtet ihr sie kurz und stellt sie dann für ein Wochenreview zurück?

Sebastian Miethe

Also wir haben noch keinen 24/7 Betrieb, deshalb auf jeden Fall als Arbeitszeit. Ich versuche mindestens wöchentlich, dass das abgearbeitet ist. Und wir haben auch noch andere Kollegen, die mit drauf gucken und momentan noch zwei Studenten, die ich damit anlerne. Also würde ich schon sagen, dass wir jetzt mehr als diese eine Stunde pro Woche verwenden. Aber wir haben ja mittlerweile auch vier Instanzen [von Rhebo Industrial Protector] und nicht mehr nur eine wie zur Anfangszeit.

Klaus Mochalski

Insbesondere wegen der Umspannwerke?

Daniel Beyer

Da ist auch ganz andere Traffic drauf, muss man sagen. Im Gegensatz zum Leitsystem. Also, es sind verschiedene Szenarien. Und da fällt schon ein bisschen mehr an.

Klaus Mochalski

Stichwort Leitsystem. Wir haben ja vor einer Weile eine Partnerschaft mit der PSI, einem großen Leitsystem-Hersteller, unterzeichnet. Eine der Ideen, die hinter dieser Partnerschaft stehen, ist letzten Endes eine Integration der Daten, die wir generieren in das Leitsystem. Also, dass man am Ende ein Betriebs-Dashboard hat, wo die normale Übersicht über die betrieblichen Parameter kombiniert wird mit einem kleinen Teil für Sicherheitsparameter.

Wie seht ihr das? Ich weiß, dass es Kunden gibt, die sagen: “Das ist eine super Idee. Dann können wir an der zentralen Stelle vielleicht auf einfache Weise und mit einem Ampelsystem Auffälligkeiten melden. Gibt es ein Sicherheitsthema, dann können die Prozesse starten.” Es gibt aber auch andere, die ganz klar gesagt haben: “Sicherheit ist ein getrenntes Thema. Das wollen wir nicht vermischen mit dem, was das Leitsystem abdeckt.” Wie ist da eure Sichtweise?

Daniel Beyer

Wir haben vor einiger Zeit auf einer Rhebo-Veranstaltung den Wunsch geäußert, dass wir gerne einige grobe Parameter exportieren und über IEC-104 in der Leitstelle bei uns zur Verfügung stellen können, weil es damals nicht anders ging.

Aber die Reise, so wie wir es jetzt aus unserem Dunstkreis mitkriegen, geht dahin, dass es perspektivisch so genannte Informations-Dispatches geben wird, die sich solche Sachen angucken. Und da wäre es natürlich sinnvoll, wenn es im PSI mit etabliert werden könnte, denn das ist das Werkzeug, womit so ein Dispatching und so eine Meldestelle arbeitet. Und ich denke, das ist eigentlich ein guter Weg.

Sebastian Miethe

Also ich halte es auch für sehr sinnvoll. Vielleicht können die Dispatcher aus der Ampel nicht so viel ablesen. Aber sie sehen auf jeden Fall, da ist irgendwas im Argen und können dann die Meldekette starten oder intern, dass man sagt “Okay, ich rufe jetzt den Bereitschaftsdienst von der IT an und die können dann was machen." Also ich denke, für den 24/7-Betrieb ist das schon sehr sinnvoll.

Daniel Beyer

Ja, absolut. Das sehe ich auch so. 

Klaus Mochalski

Ich denke auch, wenn es ein Ampelsystem wird, wenn man die Parameterlimits entsprechend justiert, kann man auch sicherstellen, dass wirklich nur bei einer gewissen Kritikalität von Ereignissen diese Meldekette losgetreten wird. Dann kann man auch existierende Ressourcen und Prozesse nutzen, und an diese die Sicherheitsthemen mit anhängen.

Daniel Beyer

Das verschafft dann letztendlich auch viel Zeit, wenn die Teams schnell informieren können, weil ihr [Rhebo] 24/7 da seid. Das ist schon viel wert.

Klaus Mochalski

Was mich auf jeden Fall noch interessiert: Was beobachtet ihr tatsächlich? Wir kennen ja alle die Meldungen aus den Zeitungen, wenn mal wieder ein Mittelständler von einer Ransomware-Attacke betroffen ist. Das sind die wenigen Situationen, wo solche Informationen nach außen dringen. Ich weiß, wir können jetzt nicht über Details sprechen, aber so generell.

Ich erzähle in meinen eigenen Webinaren und auch in dem Podcast immer wieder, dass unsere Erfahrung ist, dass die meisten unserer Kunden gerade im Bereich der Kritischen Infrastruktur hier in Deutschland sehr gut aufgestellt sind, auch schon bevor wir dort reinkommen. Und dass wir in der Regel nicht erwarten, dass dort jeden Tag, jede Woche, jeden Monat ein Angriff stattfindet, den wir aufdecken. Sondern das sind eher so die kleinen Dinge:

  • Angriffsoberfläche reduzieren,
  • eine Schwachstelle im Betriebssystem aufdecken. 
  • wenn mal ein Wartungstechniker irgendeinen Unsinn konfiguriert, dass man dem auf die Schliche kommt.

Was sind so die Dinge, die euch einfallen, die in den letzten drei Jahren aufgetreten sind, die vielleicht ein bisschen für erhöhten Puls gesorgt haben? 

Daniel Beyer

Ich gehe jetzt mal wieder ganz an den Anfang zurück. Da haben wir, so wie du schon gesagt hast, oft Techniker von uns gesehen, die sich in irgendwelchen Prozess-Netzwerken rumgetrieben haben. Das konnten wir [mit Rhebo Industrial Protector] relativ gut erkennen, weil sich bei uns die Rechner mit speziellen Namen und Suffix outen. Daher wussten wir, was da abgeht. Und konnten dann die Leute sensibilisieren. Das ist jetzt weit zurückgegangen.

Schwerwiegende Fälle hatten wir dahingehend nicht. Das einzige, was wir haben, ist, dass wir auch Datendrehscheibe für den ganzen Konzern sind. Und wir sehen mit dem Sensor jetzt, wenn aus dem Büro-Netzwerk vom Konzern Kollegen aus anderen Unternehmenssparten sich bei uns Daten abholen und das nicht so tun, wie sie es tun sollen. Dann geht bei uns natürlich der Puls hoch, wenn immens viele Datenmengen hin und her bewegt werden. Die Daten bleiben zwar Unternehmen, aber trotzdem sehen wir, da stimmt irgendwas nicht.

Klaus Mochalski

Es ist spannend, dass du das sagst. Da kann ich mich an eine Früh-Installation bei einem großen Automobilhersteller erinnern, wo wir auch eine ganze Reihe spannender Dinge gefunden haben. Und der größte Aufreger war ein Zugriff auf eine lokale Produktionsanlage aus der Konzernzentrale. Das hat für einen riesigen Aufwand gesorgt. Das war viel wichtiger als die ganzen ungepatchten Siemens-Steuerungen, die wir auch noch gefunden haben.

Sebastian Miethe

Genau. Diese Datenabflüsse oder Datentransporte sieht man halt jetzt, was man sonst nicht mitkriegen würde. Oder was auch immer mal wieder auftaucht, sind unsichere Log-Ins, wenn irgendwer sich über Uraltprotokolle irgendwo anmeldet und das auch noch in Klartext. Das sehen wir im Rhebo Industrial Protector und können dann auch mal was sagen und daran arbeiten, dass das nicht mehr verwendet wird oder zumindest ein eigenes Netzwerksegment eingerichtet wird. Ja, das sind zum Beispiel so Sachen.

Klaus Mochalski

Das ist dann auch gut für den kontinuierlichen Verbesserungsprozess. 

Daniel Beyer

Absolut.

Klaus Mochalski

Dass man immer wieder die Erinnerung bekommt, selbst wenn das jetzt nicht super kritisch ist, auch noch das letzte Risiko abzuschalten. Aber dass man eben daran denkt, dass das irgendwann mal ausgetauscht werden sollte und keine alten SMB-Versionen mehr verwenden und was da alles zusammenkommt.

Daniel Beyer

Wir hatten das oft mit Kamerasystemen, die relativ alt waren. Da wurde über Rhebo Industrial Protector das Betriebssystem gecheckt und herausgefunden, das ist schon so alt, es geht gar nicht mehr. Die haben wir dann auch direkt vom Netz genommen.

Klaus Mochalski

Das ist auch ein Problem, das nicht weggeht. Wir haben eine Auswertung der RISSA-Ergebnisse [Anm.: RISSA steht für Rhebo Industrial Security Assessment], also unseres Sicherheitsaudits, des letzten Jahres gemacht, und da hat es noch mal deutliche Verschiebungen zu den Vorjahren gegeben. Tatsächlich haben wir in der Vergangenheit “verwundbare Software” als eine Kategorie geführt. Weil das so oft auftritt, haben wir es mittlerweile aufgeteilt in verwundbare Betriebssysteme, verwundbare Software und verwundbare Firmware. Und jede Kategorie für sich tritt noch in der Regel bei über 50 % dieser Audits auf. Das heißt, das ist nach wie vor ein sehr verbreitetes Thema. Selbst im Jahr 2023.

Was mich als letztes Thema noch interessiert: Viele Kritische Infrastruktur-Betreiber hatten zum 1. Mai 2023 einen ganz wichtigen Termin, nämlich die Erfüllung der Anforderungen des novellierten IT-Sicherheitsgesetzes. Das gibt es schon eine ganze Weile. Relativ neu ist die Orientierungshilfe, die das Bundesamt für Sicherheit in der Informationstechnik im letzten Jahr mit etwas Verspätung herausgegeben hat. Und dabei wird ja noch mal konkretisiert, welche Anforderungen sich aus dem IT-Sicherheitsgesetz konkret ergeben. Wir haben das für unsere Kunden in einer tabellarischen Übersicht aufgearbeitet, weil manche Anforderung im BSI-Dokument so ein bisschen unklar, vielleicht auch schwammig formuliert war.

Wie seid ihr damit umgegangen? Habt ihr euch die Orientierungshilfe tatsächlich als Richtlinien-Dokument angenommen? Und wie ist der Stand bei euch heute?

Sebastian Miethe

Wir haben das Dokument auf jeden Fall. Es ist natürlich ein Haufen Prosa. Das mussten wir erst mal durchgehen, für uns ein bisschen kategorisieren und es in Tabellenform fassen, wo man dann abhaken konnte, was wir machen und was wir nicht machen. Und zu entscheiden, bei welchem System wir noch nacharbeiten müssen. 

Und im Endeffekt sind wir eine zweigleisige Strategie gefahren. Einmal mit dem Rhebo-System als netzwerkbasierte Anomalieerkennung und dann noch ein SIEM-System, um den Anforderungen genüge zu tun.

Klaus Mochalski

Das ist spannend mit dem SIEM-System. Da gab es ja tatsächlich, auch wenn man die Revision des Dokumentes verfolgt hat, ein ziemliches Hin und Her. In der vorletzten Revision wurde tatsächlich explizit ein SIEM-System gefordert und man hätte das sogar so lesen können, dass man mit dem SIEM-System auf der sicheren Seite ist.

Daniel Beyer

Haben auch viele so getan.

Klaus Mochalski

Dabei ist ein SIEM allein mitnichten die sinnvolle Lösung! Denn dessen Performance hängt ja davon ab, welche Daten ich mit dem SIEM-System verarbeitete. Das heißt, ein SIEM-System alleine nützt mir gar nichts. Diese Passage ist dann am Ende wieder rausgefallen. Aber ihr macht beides. Das ist gut.

Das sehen wir auch als sinnvoll an. Wir als Anbieter eines solchen Systems zur Angriffserkennung lesen das natürlich so, dass die Überwachung der Protokollparameter nur funktioniert, wenn man wirklich die Netzwerkkommunikation überwacht. Denn sonst besteht die Datenquelle für SIEM-Systeme nur aus Log-Nachrichten [aus anderen Systemen].

Sebastian Miethe

Endgeräte im Endeffekt.

Klaus Mochalski

Endgeräte, die Log-Nachrichten produzieren. Und das bedeutet, dass am Ende der Programmierer der Software auf dem Endgerät entscheidet, welches Ereignis geloggt wird und welches nicht. Das heißt, man verlässt sich auf bestimmte Dinge.

Der Kern so eines Anomalieerkennungssystems ist ja, dass wirklich jede Veränderung in der Netzwerkkommunikation, auch Dinge, die wir nie vorhergesehen haben, eine Meldung erzeugt. Und das ist bei Log-Nachrichten [von Endgeräten] eben nicht der Fall. Deswegen halten wir die Netzwerküberwachung für ein ganz wichtiges Element.

Noch mal zur Orientierungshilfe. Es gibt ja am Ende diese Umsetzungsgrade von 0 bis 5, die zwischendurch mal Reifegrad hießen. Level 3 ist so der Standard, den alle versuchen oder versucht haben, zum 01. Mai zu erreichen. Wo steht ihr da aktuell und gibt es darüber hinaus eine Planung?

Daniel Beyer

Ja. Also, wir haben die Stufe drei im April erreicht. Und in zwei Jahren ist das nächste Audit. Dann müssen wir eine Stufe hoch. Das ist auf jeden Fall auch unser Ziel, das zu erreichen.

Sebastian Miethe

Wir konnten auf jeden Fall unseren Prüfer mit unseren Systemen an der Stelle überzeugen. Er fand es auch sehr gut, dass wir die netzwerkbasierte Angriffserkennung von Rhebo einsetzen und damit neben den organisatorischen Prozessen und Richtlinien auf jeden Fall den Reifegrad 3 umsetzen konnten.

Klaus Mochalski

Glückwunsch dafür. Habt ihr ein Gefühl dafür, ob ihr da in guter Gesellschaft seid? Ist das allen gelungen oder gibt es hier viele KRITIS-Unternehmen, die da noch nachbessern müssen?

Daniel Beyer

Uns ist nur ein Unternehmen bekannt, wo es nur die 2 wurde, die aber nachbessern konnten. Ansonsten haben wir gar keinen Einblick, wer jetzt was erreicht hat. Es wird auch nicht so transparent kommuniziert vom BSI an sich.

Klaus Mochalski

Es ist natürlich einerseits verständlich, dass solche Informationen nicht öffentlich geteilt werden. Aber ich glaube, gerade in der Community der Kritischen Infrastrukturbetreiber ist so ein Austausch ganz gut. Das man sich austauscht über: Was sind eure Erfahrungen? Wie sind eure Abläufe? Welche Erfahrungen habt ihr mit bestimmten Werkzeugen gemacht?

Denn wir haben über SIEMs gesprochen. Am Ende steht und fällt ja die Effizienz und Effektivität eines SIEM mit den Use Cases, die man abbildet. Wie gut hat man das eigene Unternehmen, die eigene Infrastruktur abgebildet? Und da wäre so ein Erfahrungsaustausch natürlich viel wert. Das sollte man auf jeden Fall auch mal rückmelden, dass das in irgendeiner Form vielleicht ermöglicht werden kann.

Sebastian Miethe

Ich bin auch in einer Projektgruppe namens IKT. Mit anderen Netzbetreibern von Hamburg bis Thüringen gab es da auch vor dem Audit [nach IT-SiG 2.0] schon Austausch, was jeder so macht und für richtig hält. Eine Nachbesprechung soll es noch geben. Wir haben dann wahrscheinlich mehr Erfahrung, wie es bei den anderen so lief. 

Klaus Mochalski

Das ist auf jeden Fall spannend. Ich glaube, man muss da auch eine Lanze für das BSI brechen, weil ich glaube, die kriegen sehr viele, häufig diametral entgegengesetzte Anforderungen, Wünsche von den verschiedenen Unternehmen.

Daniel Beyer

Das denke ich auch.

Klaus Mochalski

Die einen wollen gerne diese Informationen tauschen, andere wiederum wollen am liebsten gar nichts anbieten. Und das ist natürlich schwierig in diesem Spannungsverhältnis.

Ich fände es sehr gut, wenn wir uns in, sagen wir mal, zwei Jahren wieder treffen und dann schauen, wo wir, wo ihr dann steht. Was sind denn eure Pläne für die nächsten zwei Jahre mit dem System? Was sind die nächsten großen Schritte, die ihr vorhabt? Umsetzungsgrad 4 hatten wir schon gesagt. 

Sebastian Miethe

Das auf jeden Fall. Vielleicht auch gleich 5, mal gucken. Hinsichtlich Rhebo ist für uns auf jeden Fall die Zusammenarbeit mit dem PSI-System interessant. Da denke ich mal, werden wir vielleicht bei uns noch eine fünfte Instanz etablieren, damit wir noch mehr Einblicke im Kernsystem vom Leitsystem haben.

Klaus Mochalski

Da geht es da um die Überwachung der Kommunikation zum Leitsystem oder geht es um die Integration in den Leitstand selbst?

Daniel Beyer

Um die Kommunikation innen. Wir haben jetzt alles extern gemacht, alles abgegrast. Jetzt wollen wir auch mal in das System reingucken. Nicht, dass uns da irgendwas unterläuft, und wir kriegen es zu spät mit.

Sebastian Miethe

Ansonsten natürlich die Erschließung der Umspannwerke. Das ist ein laufender Prozess, sage ich mal. Und was auch noch ein Thema ist, ist die bessere Auswertung der Syslog-Daten von Rhebo in unserem  SIEM-System. Also Integration von Rhebo und Korrelation von den Netzwerkdaten, die wir von Rhebo Industrial Protector bekommen, mit den Endgeräte-Logs.

Klaus Mochalski

Das sehen wir auch als gutes Thema. Wenn aus dem Netzwerkverkehr Daten herausgezogen werden, die dann mit Loginformationen, also mit Logdaten aus verschiedensten Systemen wie Firewalls und Server-Systemen, kombiniert werden können. Da kann man unter Umständen auch viel, viel schneller Dinge analysieren, wo man heute noch ein bisschen Netzwerk-Forensik betreiben muss. Und insofern ist das dann auch wieder in Hinblick auf schnelles Arbeiten eine ganz wichtige Entwicklung.

Daniel Beyer

Definitiv ja.

Klaus Mochalski

Okay, es hat großen Spaß gemacht. Ich glaube, das war ein sehr guter Einblick für unsere Hörer:innen. Vielen Dank, Daniel. Vielen Dank, Sebastian. Ich freue mich auf jeden Fall auf die nächste Episode und wünsche euch bis dahin alles Gute. Dass es weiterhin so bleibt, dass ihr keine Vorfälle bei euch zu verzeichnen habt bzw. kein ernsthaften.

Daniel Beyer

Das wünschen wir uns auch. Vielen Dank.

Sebastian Miethe

Vielen Dank!