Klaus Mochalski
Hallo und willkommen zu einer neuen Folge des Rhebo-Podcasts OT Security Made Simple. Heute sitze ich hier bei einem Partnerunternehmen von Rhebo, Digital Forensics, und bei mir ist der Gründer und CEO Frank Stummer. Zur vollständigen Offenlegung, Frank Stummer ist auch ein Gründer von Rhebo und arbeitet seit vielen, vielen Jahren für und mit Rhebo. Wir kennen uns also recht gut. Aber Frank, erzähl uns ein wenig über dich und was du mit Digital Forensics machst.
Frank Stummer
Ja, ich danke dir sehr, Klaus. Und nicht nur, dass wir uns sehr gut kennen, auch sehr lange. Aber das ist eine andere Geschichte. Was ich hier bei Digital Forensics mache, ist in der Tat digitale Forensik, das heißt, wir kommen in Projekte oder in Fälle, in denen Industrieunternehmen angegriffen, gehackt oder was auch immer werden. Wenn es also einen Sicherheitsverstoß, ein Sicherheitsereignis oder etwas Ähnliches gibt, kommen wir ins Spiel, um zu ermitteln und zu analysieren, was passiert ist. Und am besten auch, um weitere Details zu erfahren, vielleicht auch um den Angreifer, den Hacker, vor Gericht zu bringen. Das wäre natürlich die beste Lösung.
Klaus Mochalski
Das ist sehr interessant. Bevor wir also darüber sprechen, was Forensik, digitale Forensik für den Bereich der OT-Sicherheit bedeutet, kannst du unseren Zuhörern vielleicht ein wenig Hintergrundwissen über dich selbst geben und wie du in den Bereich der digitalen Forensik gekommen bist.
Frank Stummer
Ja, das ist eine lustige Geschichte. Ursprünglich bin ich kein Forensiker, ich bin nicht einmal ein Techniker. Ich bin eher ein Finanztyp. Ich habe Wirtschaftswissenschaften studiert, und in unserem ersten Unternehmen war ich eigentlich der Finanzchef. Aber dann wurde ich sehr bald auch Teil des Verkaufsprozesses und des Produktmanagementprozesses. Ich war also an der Entwicklung von Produktlösungen beteiligt, aber auch an der Nutzung dieser Lösungen. Und sehr, sehr bald wurde ich auch Teil des forensischen Bereichs unseres Unternehmens. Und das ist etwas, das mich wirklich gefesselt hat, denn es geht nicht nur um Daten, um Technologie oder was auch immer, sondern es hat auch mit Menschen zu tun. In der Tat. Also, forensische Analyse hat immer auch mit der Überlegung zu tun, okay, wer ist vielleicht der Angreifer? Was sind die Prozesse hinter so einem Angriff? Was ist passiert? Und das ist etwas, worauf ich immer sehr neugierig bin, nicht nur die technische Seite, sondern auch, sagen wir mal, die menschliche Seite solcher Prozesse.
Klaus Mochalski
Ja, wie man in der Sicherheitsbranche sagt, geht es am Ende immer um die Menschen und nicht um die Systeme oder Werkzeuge. Es geht um die Menschen. Also, sehr wichtig. Aber nun weg von der allgemeinen IT-Sicherheit hin zur OT-Sicherheit, der Steuerungstechnik, d. h. dem Teil der IT, der industrielle Kontrollsysteme und Automatisierungsprozesse verwaltet und steuert. Wir befinden uns also wieder in einem Umfeld, in dem es plötzlich weniger Menschen und mehr Maschinen und Systeme gibt. Welche spezifischen Anwendungen oder Anwendungsfälle hast du in den letzten Jahren für die digitale Forensik in der OT-Sicherheit gesehen? Und was, wenn überhaupt, macht die Forensik dort so besonders?
Frank Stummer
In der OT-Sicherheit gibt es zwei Besonderheiten, würde ich sagen. Die eine macht es einfacher, forensische Analysen durchzuführen, die andere macht es komplexer. Eine Sache, die die forensische Analyse in der OT-Umgebung viel einfacher macht als in der Büro-IT-Umgebung, ist, dass wir es hier mit Maschinen zu tun haben, die am Ende des Tages mit anderen Maschinen kommunizieren. Und das bedeutet, dass wir einen sehr hohen Grad an Determinismus haben. Auf der Grundlage dieses Prinzips ist die [Kommunikation] vergleichbar, und es ist recht einfach zu erkennen, was nicht normal ist.
Klaus Mochalski
Es ist also besser vorhersehbar, was passieren soll und was nicht.
Frank Stummer
In der Tat. Und das ist die eine Seite. Aber auf der anderen Seite ist es natürlich die OT-Seite. In Wirklichkeit ist sie in jedem Unternehmen, in dem ich je war, viel komplexer und komplizierter als die IT-Seite, was bedeutet, dass wir dort viel mehr Anlagen haben. Wir haben viel mehr Knotenpunkte in einem Netzwerk, die miteinander kommunizieren. Wir haben viel mehr IP-Adressen. Viele wissen das nicht. Ich schätze, dass vor fünf Jahren oder so die reine Anzahl der IP-Adressen im OT-Bereich viel höher war als die Anzahl der IP-Adressen im Büro-IT-Bereich.
Klaus Mochalski
Das ist wahrscheinlich interessant zu betrachten. Die Leute neigen dazu, zu vergessen, dass es in der IT-Umgebung ein paar Oberflächensysteme gibt und auf der anderen Seite einen Computer, den jeder Mitarbeiter vor sich stehen hat, und das ist im Grunde die Anzahl der Systeme, mit denen man es zu tun hat. Vielleicht noch ein paar Drucker, aber das war's dann auch schon. Wenn man hingegen in eine Fabrik geht, in die Werkshalle, dann hat man alle Maschinen, alle Steuerungen der Maschinen, aber auch die Gebäudeautomatisierungssysteme, die IP-Kameras, die man betreibt, man hat vielleicht viele Sensoren, die alle mit dem Netzwerk verbunden sind. Man sieht also leicht, wie diese schiere Anzahl zu explodieren beginnt.
Frank Stummer
Ja, das stimmt, aber es gibt auch eine Menge Gemeinsamkeiten zwischen OT und IT. Zum Beispiel wird alles von Menschen konfiguriert, von IT-Administratoren am Ende des Tages, richtig?
Klaus Mochalski
Und Windows benutzt man immer noch, obwohl man hofft, dass es bald abgeschafft wird, oder?
Frank Stummer
Ja, natürlich haben wir auf der OT-Seite noch eine Menge älterer Assets und einige alte Firmware-Versionen, aber aus bestimmten Gründen ist es in Ordnung, dort altes Zeug zu verwenden, wenn man andere Möglichkeiten hat. Wenn man in sichere Umgebungen kommt, dann kann man natürlich auch alle Firmware-Versionen verwenden, das ist in Ordnung. Und übrigens ist es nicht so alt, wie viele Leute denken. Also es ist älter und wir haben mehr Assets, und manchmal haben wir auch ältere Assets, aber es ist auch modern. Natürlich ist es modern, so wie der IT-Sektor es auch ist.
Klaus Mochalski
Ja, das stimmt. Schauen wir uns also die Besonderheiten der forensischen Analyse an. Was bedeutet das? Und vielleicht können wir in diesem Zusammenhang unseren Zuhörern kurz erklären, was das Rhebo-System macht. Rhebo baut also ein System zur Erkennung von Anomalien. Wir überwachen den Netzwerkverkehr und suchen nach Ereignissen, die verdächtig aussehen, die vom Üblichen abweichen. Und dann erstellen wir nicht nur Warnungen über ungewöhnliche Ereignisse, sondern wir zeichnen auch immer einen Ausschnitt des Netzwerkverkehrs auf. So kann man bei der forensischen Analyse in der Zeit zurückgehen, wie bei einem Videorekorder, mit einem Rekorder, und sich ansehen, was wirklich passiert ist. Es geht also nicht nur darum, sich auf unser System zu verlassen und die richtigen Alarme mit allen notwendigen Kontextinformationen auszulösen, sondern Rohdaten zu sammeln, die wir dann an einen Analysten weitergeben können, der dann aus diesen Ausschnitten das machen kann, was er oder sie will oder braucht. Das ist für uns wirklich der Übergabepunkt und der Beginn der forensischen Analyse. Wie geht es aus der Sicht eines Dienstleistungsunternehmens, das diese Dienste anbietet, weiter? Was sind die nächsten Schritte? Was macht ihr normalerweise mit diesen Informationen und was holt ihr heraus?
Frank Stummer
Genau das, was du gesagt hast. Der erste Schritt ist, sich ein Bild davon zu machen, wie das System aussieht, wie das Netzwerk aussieht, welche Ressourcen vorhanden sind. Das bekomme ich z. B. direkt aus dem Rhebo-System oder anderen Systemen. Und das ist gut. Für den ersten Überblick, sozusagen. Aber genau das, was ich dann wirklich in der Tiefe analysieren muss, steckt in den Rohdaten. Und in der Netzwerkkommunikation bedeuten Rohdaten zum Beispiel PCAPs, also wirklich Packet Captures der Netzwerkkommunikation, komplett original und nicht manipuliert. Die Rohdaten, wie sie sind oder wie sie waren. Und genau eine der besten Funktionen der Rhebo-Lösung ist diese kleine Funktion zum Einfangen der Schnipsel der Netzwerkkommunikation.
Das erleichtert mir am Ende des Tages die Arbeit, denn ich kann einfach die PCAPs holen, die nicht so groß sind, diese Daten, und ich kann wirklich bis zu den letzten Bits und Bytes der alten Daten gehen. Und dann ist es unsere Aufgabe, wirklich zu schauen, was im Detail passiert ist. Gibt es irgendetwas, nicht nur verdächtige Kommunikation, sondern was genau ist verdächtig? Da sind zum Beispiel die Daten. Sind da falsche Informationen drin, oder ist da Schadsoftware drin oder etwas anderes? Und genau das ist es, was wir tun. In den meisten Fällen suchen wir also manuell mit Hilfe von Tools, aber letzten Endes ist es immer noch viel Handarbeit. Wir analysieren jedes Bit, jedes Byte in den Rohdaten.
Klaus Mochalski
Nun, für mich als Vertreter von Rhebo ist das etwas enttäuschend, denn ich würde unser System gerne als ein System sehen, das die meisten Informationen liefert, die man für die Analyse eines Vorfalls braucht. Aber ich kann auch verstehen, dass dies nicht immer und in jeder Situation ausreicht. Und deshalb sehe ich, dass der Zugang zu den Rohdaten für Analysten für die Post-Mortem-Analyse sehr wertvoll ist, insbesondere nach einem Vorfall. Vielleicht können unsere Zuhörer besser verstehen, wie dieser Prozess der Analyse eines Vorfalls aussieht. Fällt dir ein aktuelles Beispiel ein, bei dem du eine solche Analyse durchgeführt und ein solches Erkennungssystem verwendet hast?
Frank Stummer
In einer OT-Umgebung, ja. Aber vorher muss man verstehen, dass die forensische Analyse eigentlich immer der letzte Schritt ist. In den meisten Fällen von Sicherheitsvorfällen in einem Unternehmen findet die forensische Analyse gar nicht statt.
Klaus Mochalski
Man kommt also nur dorthin, wenn vorher etwas schief gelaufen ist. Ja.
Frank Stummer
Also wirklich post mortem, dieser lateinische Ausdruck gefällt mir sehr gut. Man macht [die forensische Analyse] manchmal mit sehr viel Aufwand, aber nur, wenn es wirklich wichtig ist. Zum Beispiel, um wirklich zu sehen, was genau dort passiert ist, oder um einen Angreifer zu fangen. Ich würde sagen, dass man nur in weniger als 1 % der Sicherheitsvorfälle, oder viel weniger als 1 % der Sicherheitsvorfälle, wirklich eine forensische Analyse durchführt, weil sie für die anderen 99 % nicht benötigt wird.
Klaus Mochalski
Je weniger die Kunden also einen forensischen Analysten zu Gesicht bekommen, desto besser für sie.
Frank Stummer
Ja, in der Tat. Wenn sie meine Dienste benötigen, dann ist [die Situation] eines Kunden nicht schön. Aber um dir ein Beispiel zu geben: Wir haben vor zwei, drei Jahren eine forensische Analyse durchgeführt. Natürlich [werde ich den Namen nicht nennen], aber es war ein größeres Unternehmen. Ein 2-3-Milliarden-Euro-Konzern im Bereich der Logistik.
Klaus Mochalski
Gehörten sie zu den kritischen Infrastrukturen im Sinne der lokalen Gesetzgebung?
Frank Stummer
Damals noch nicht. Sie wird jetzt mehr und mehr Teil der Sicherheitsgesetze, aber nicht zu dieser Zeit. Aber was dort geschah, war: Wir bekamen einen Anruf. Normalerweise bekommen wir keinen Anruf von einem direkten Endkunden, sozusagen. Aber wir bekamen einen Anruf von einer IT-Sicherheitsfirma, unserem Partner, und die sagten, hier ist etwas passiert. Und tatsächlich, mit diesen Worten: "Hier ist etwas passiert."
Klaus Mochalski
Es handelte sich um ein Dienstleistungsunternehmen, das Dienstleistungen für den Endkunden erbringt.
Frank Stummer
Ja, für den Endkunden. Dieses Unternehmen bietet auch SOC-Dienste, Security Operations Center, für den Endkunden an. Und das ist gut. Aber manchmal wissen sie auch nicht, was genau dort passiert ist. Aber natürlich sagten sie, sie hätten ein Sicherheitsereignis gesehen. Aber das Sicherheitsereignis war genau in diesen Worten: Hier ist etwas passiert. Beim Kunden handelte es sich also um einen Hersteller von Logistiksystemen, der viele Kunden in der ganzen Welt hat. Und ganz plötzlich stand an zwei oder drei Endkundenstandorten die gesamte Produktion still. Die kompletten Logistiklinien wurden gestoppt.
Klaus Mochalski
Das ist also wirklich der schlimmste Fall, den man in einer Produktionsumgebung niemals erleben möchte.
Frank Stummer
Ja. Und innerhalb weniger Wochen gab es Verluste in Höhe von etwa 200 bis 300 Millionen Euro. Wir sprachen also über einen sehr wichtigen Produktionszyklus.
Klaus Mochalski
Es war also wirklich ein wichtiger Vorfall?
Frank Stummer
Ja, ein wirklich großer Vorfall. Aber sie wussten nicht, was dort geschah. Sie sahen nur die Ergebnisse, und die Ergebnisse waren: Okay, zwei, drei der Standorte sind einfach stehen geblieben! Aber sie wussten nicht wirklich, was da genau passiert war. Es gab also einige Ideen, sozusagen am Anfang, nur Ideen, weder negativ noch positiv. Nur Ideen, neutrale Ideen.
Eine war, okay, es gibt eine Fehlkonfiguration, irgendetwas war falsch mit der Lösung selbst. Das kann passieren. Und die zweite Idee war, dass es einen Angriff gab. Es war ein Angriff im Gange, mit einigen verschiedenen Unterkategorien, was dort passieren könnte. Und [Digital Forensics] kam natürlich für diesen zweiten Weg der Analyse in dieses Projekt.
Und wir haben alles analysiert, was wir hatten. Aber es war nicht sehr viel. Wir hatten zu diesem Zeitpunkt nicht viele Rohdaten.
Klaus Mochalski
Ich nehme an, ihr habt euch hauptsächlich die Protokolldaten [bzw. Log-Dateien] angesehen?
Frank Stummer
Ja, einige Protokolldaten. Aber im OT-Sektor, und insbesondere vor drei Jahren, sind nicht so viele Protokolldaten verfügbar. In der IT gibt es viel mehr Protokolldaten. Aber nicht im OT-Sektor, denn viele der Server haben keine Protokollierungsfunktionen. Wir waren also nicht in der Lage zu sehen, was dort in erster Instanz passiert ist. Was wir also taten, war zu sagen: "Wenn dies ein Angriff war, wird der Angreifer vielleicht irgendwann in der Zukunft wieder angreifen."
Also installierten wir ein System, das auch das Rhebo [OT-Sicherheitsmonitoring]-System nutzte, um die gesamte Kommunikation von der Zentrale zu allen Kunden und Kundenstandorten zu überwachen. Und natürlich hatten wir einige Ideen, wo ein solcher Angriff stattfinden könnte. Und dann haben wir es einfach überwacht. Und tatsächlich geschah dieser Angriff nach acht Monaten erneut. Und wir haben ihn direkt und in Echtzeit überwacht [und entdeckt]. Und natürlich haben wir den Angriff sofort gestoppt, damit sich die 200 bis 300 Millionen Euro schweren Vorfälle nicht wiederholen konnten. Aber wir haben diesen Angriff wieder gesehen, und es war wirklich ein Angriff von innen. Es kam also nicht von außen, es war kein Konkurrent oder ein fremder Staat oder was auch immer. Nein, er kam wirklich von innen, dieser Angreifer.
Klaus Mochalski
Um dies besser zu verstehen. Es ist offensichtlich, dass dem Kunden die Erkennungsmöglichkeiten fehlten. Zunächst reichten die Protokolldaten nicht aus, und dann wurde ein [OT-Angriffs-] Erkennungssystem implementiert. Und das System half nicht nur bei der Bereitstellung forensischer Daten, sondern erkannte auch, so nehme ich an, die Anomalie im Zusammenhang mit diesem verdächtigen Verhalten und löste die ersten Benachrichtigungen aus. Wenn der Kunde also von Anfang an ein solches Erkennungssystem eingesetzt hätte, wäre er in der Lage gewesen, die Anomalie zu erkennen, als sie das erste Mal auftrat.
Frank Stummer
Ja, in der Tat, denn der Angriff selbst war ziemlich einfach, würde ich sagen.
Klaus Mochalski
Nichts besonderes.
Frank Stummer
Nichts Ausgefallenes. Und es war auch keine, sagen wir mal, Schadsoftware oder ähnliches. Was tatsächlich passiert ist, war, dass einer der Ingenieure dort in der Zentrale außerhalb der normalen Fernwartungszeiten einen "Shut down"-Code an die Systeme geschickt hat.
Klaus Mochalski
Die Person nutzte also ihr Insiderwissen und schaltete einfach die richtigen Systeme ab, wohl wissend, dass einige wenige die gesamte Produktionsinfrastruktur zum Absturz bringen würden.
Frank Stummer
Ja. Und er hat nicht versucht, etwas zu verbergen. Es war wirklich eine offene Kommunikation. Sie war nicht verschlüsselt oder ähnliches, es war einfach eine Kommunikation. Die Abschaltung der Systeme da draußen erfolgte über den normalen Kommunikationsweg. Wir haben die Rohdaten aufgezeichnet, wir haben sozusagen alle "smoking guns" aufgezeichnet.
Aber was dann geschah, war ein bisschen schade.
Wir konnten wirklich sehen, dass es genau dieser Server mit diesem Benutzernamen war, der zu diesem Zeitpunkt, zu diesem Datum, die Abschaltung gesendet hat. Aber im Nachhinein - und das ist leider nicht mehr unsere Aufgabe, sondern die der Kundenfirma - haben sie herausgefunden, dass 300, 400 Leute - sie wussten nicht einmal die genaue Zahl - denselben Benutzernamen haben. Sie hatten also keine guten Regeln, sozusagen, keine Prozesse für individuelle Konten, für individuelle Anmeldungen zumindest, oder so etwas.
Klaus Mochalski
Es handelt sich also um einen typischen Fall dieser wohlbekannten Sicherheitslücken, die jeder kennt, wie gemeinsamer Benutzername, Passwort, [USB]-Stick für den Monitor.
Frank Stummer
Ja, jahrelang stand das Passwort im Intranet. Und das Intranet war zumindest nicht sehr sicher. Das ist also nicht lustig, sondern wirklich ernst, aber etwas, das ich leider sehr oft sehe. Und danach haben sie natürlich ein großes Projekt gestartet, um wirklich gute Prozesse einzurichten, individuelle Konten und all diese Dinge. Und das ist natürlich notwendig. Und das ist es, was ich gesagt habe. Es hat immer etwas mit Menschen und Prozessen und Regeln und all diesen Dingen zu tun. Und all die technischen Systeme, das Überwachungssystem, die Analysen - was ich mache - kommen sozusagen am Ende.
Klaus Mochalski
Es ist interessant, einen so konkreten Fall zu sehen. Ich meine, es wurde viel über Insider-Angriffe gesprochen und darüber, wie gefährlich und schwer zu verhindern sie sein können. Aber hier handelt es sich um ein konkretes Beispiel, das zeigt, dass es nicht einfach mit Systemen wie einer Firewall zu lösen ist. Das hilft hier eindeutig nicht weiter. Und viele Unternehmen gehen aus unserer Sicht immer noch davon aus, dass sie ihre Hausaufgaben gemacht haben, wenn sie ihre Perimetersicherheit, also die Sicherung des digitalen Eingangs ihrer Infrastruktur, gewährleisten. Und dieser Fall zeigt deutlich, dass das nicht der Fall ist.
Es geht also um die interne Organisation, die Mitarbeiter und den Schutz der Netzwerksegmente. In letzter Zeit hören wir viel über Segmentierungsprojekte, Mikrosegmentierungsprojekte, und das ist wirklich hilfreich. Es zeigt aber auch, dass man über die entsprechenden Fähigkeiten zur Angriffserkennung verfügen muss. Das könnte die Protokollüberwachung durch das SOC und ein SIEM-System sein. Es könnte ein spezielles System zur Erkennung von Anomalien sein. Aber diese Systeme müssen in die Organisationsstrukturen eingebunden sein.
Frank Stummer
Ja, in der Tat. Zumindest ist das Privilegienmanagement hier sehr wichtig und all diese Ansätze.
Klaus Mochalski
Vielleicht sogar Zero-Trust, was in der Tat ein sehr aktuelles Thema ist.
Frank Stummer
Bis jetzt, nicht nur vor drei Jahren, sondern bis jetzt, mangelt es in dieser Hinsicht in den meisten Unternehmen wirklich. Das beginnt sich jetzt zu ändern. Auch im OT-Sektor zusammen oder auf der Grundlage neuer Vorschriften wie der neuen NIS2 in Europa oder NIST in Amerika, dem IT-Sicherheitsgesetz in Deutschland, um genau zu sein. Und das ändert sich jetzt auf der Grundlage von Normen wie ISO 27000 und ISO 270001.
Klaus Mochalski
Ich denke, es ist auch eine Frage des Bewusstseins. Das Bewusstsein wächst. Und hier hilft die Gesetzgebung. Also vielen Dank für den Einblick. Ich denke, das ist wirklich hilfreich, denn statistisch gesehen sind die Fälle, die wir bei unseren Kunden beobachten, in der Regel viel weniger aufregend. So finden wir bei unseren regelmäßigen [OT-Schwachstellenbewertungen] veraltete Firmware, veraltete Betriebssystemsoftware. Wir finden Kommunikation, die eigentlich nicht stattfinden sollte, aber keine wirklich kritischen Ereignisse oder Vorfälle. Das zeigt, dass es entweder bereits ein hohes Maß an Sicherheitsstandards gibt oder dass die Dinge, die passieren können, nicht allzu oft vorkommen. Umso interessanter ist es, etwas über einen solchen speziellen Fall zu erfahren.
Frank Stummer
Ja.
Klaus Mochalski
Wenn du ein Fazit ziehen könntest, eine Lehre für Kunden in der Fertigung oder sogar im Bereich kritischer Infrastrukturen, die ihre Umgebungen gegen Insider-Angriffe schützen wollen, was müssten sie tun?
Frank Stummer
Wenn du erlaubst, würde ich zwei Dinge festhalten. Es können auch drei sein.
Klaus Mochalski
Ein Tipp ist vermutlich zu wenig.
Frank Stummer
Ja, der erste Punkt sind in der Tat die Sicherheitsprozesse. Und auch die Arbeitssicherheit beginnt übrigens mit guten Prozessen, mit guten Abläufen und mit dem Bewusstsein der Menschen. Das ist immer das Wichtigste, was man etablieren sollte.
Klaus Mochalski
Ohne diesen Aspekt ist jede technische Maßnahme höchstwahrscheinlich wertlos.
Frank Stummer
Ja, in der Tat. Und die zweite Schlussfolgerung für Unternehmen wie Rhebo, aber auch für die Endnutzer ist: Man sollte auch auf forensische Analysen vorbereitet sein, denn wenn etwas sehr Ernstes, sehr Wichtiges passiert, dann ist es wirklich wichtig zu wissen, was vorgefallen ist, um es vielleicht in Zukunft zu verhindern, oder? Und zum anderen, wenn möglich, auch, um den Angreifer wirklich zu fangen.
Klaus Mochalski
Und man will den Angreifer gleich fangen und nicht, wie in diesem Fall, acht Monate warten, bis es wieder passiert, richtig?
Frank Stummer
Und deshalb kann ich als forensischer Analyst nur sagen: Bitte geben Sie uns die Möglichkeit, wirklich etwas zu analysieren, die Daten zu analysieren. Es geht [bei einem OT-Angriffserkennungssystem] also nicht nur um die Überwachung, sondern auch darum, die Rohdaten, die PCAPs, die Protokolle und so weiter zu erhalten. Das sind sehr wertvolle Daten und Informationen, die wir bei unserer Arbeit nutzen können, aber manchmal vergessen [die Unternehmen], an solche Informationsmöglichkeiten und -quellen zu denken.
Klaus Mochalski
Also wieder eine Mischung aus Organisationen und den richtigen Werkzeugen. Und was die Werkzeuge angeht, so sollte man nicht übersehen, dass man immer in der Lage sein muss, genügend Daten zu sammeln, um eine, wie du es nanntest, Post-Mortem-Analyse durchzuführen.
Frank Stummer
Ja. Also die Daumen drücken, dass natürlich erst einmal nichts passiert. Aber wenn doch, dann hat man zumindest die Möglichkeit, zu analysieren, was passiert ist, um tatsächlich vorbereitet zu sein.
Klaus Mochalski
Ja, ich denke, das ist eine sehr gute Schlussfolgerung. Vielen Dank für diese interessante Diskussion und die Präsentation dieses speziellen Falles. Es war mir ein Vergnügen, dich dabei zu haben.
Frank Stummer
Danke dir auch vielmals.
NACHTRAG: Der beschrieben Sicherheitsvorfall ist auch als Case Study (pdf) zum Download verfügbar.
