#65 Incident Response
Was im Ernstfall wirklich zu tun ist
27.03.2026 65 min
Zusammenfassung & Show Notes
Ein Incident ist kein reines Technikproblem – er betrifft das gesamte Unternehmen. Wir sprechen darüber, was im Ernstfall wirklich passiert, warum Chaos oft in den ersten Minuten entsteht und welche Sofortmaßnahmen entscheidend sind. Wir zeigen, warum ein funktionierender Notfallplan, klare Rollen und eine strukturierte Kommunikation über Erfolg oder Scheitern entscheiden. Außerdem wird deutlich: Incident Response beginnt lange vor dem eigentlichen Angriff – nämlich bei Vorbereitung, Übungen und klaren Prozessen.
IT-Sicherheitsvorfälle gehören heute zum Alltag vieler Unternehmen. Doch im Ernstfall zeigt sich schnell, ob ein Unternehmen vorbereitet ist oder improvisieren muss.
Wir beleuchten in dieser Episode die organisatorischen und technischen Aspekte der Incident Response – von den ersten Minuten eines Angriffs bis zur Wiederherstellung des Betriebs. Wir zeigen typische Fehler auf, erklären die Rolle von Notfallplänen und Krisenkommunikation und machen deutlich, dass Incident Response ein Zusammenspiel aus Technik, Management und Kommunikation ist.
Die wichtigste Erkenntnis: Ein funktionierendes Incident-Management entsteht nicht im Ernstfall, sondern lange davor – durch Planung, Dokumentation und regelmäßige Übungen.
Soundbites
Soundbites
- Incident Response ist kein IT-Problem – es ist ein Unternehmensproblem.
- Die ersten Minuten eines Angriffs entscheiden oft darüber, wie groß der Schaden am Ende wird.
- Wer im Ernstfall erst nach einem Forensiker sucht, hat schon verloren.
- Ein Notfallplan hilft nur dann, wenn er auch erreichbar ist – selbst wenn die IT komplett ausgefallen ist.
- Die IT kann technische Maßnahmen empfehlen – strategische Entscheidungen trifft immer das Management.
- Ein Backup ist wichtig – aber hektisch eingespielte Backups können den Schaden sogar vergrößern.
- Klare Kommunikation verhindert Panik – und schützt gleichzeitig die Reputation des Unternehmens.
- Der wichtigste Schritt nach einem Angriff ist nicht der Neustart – sondern das Lernen daraus.
Transkript
Ziemlich passender Einstieg. Lass' podcasten, genau so.
Lass' podcasten.
Moin Michael.
Moin René, grüß dich.
Ja, letztes Mal habe ich schon gesagt und diesmal auch wieder, du bist besser zufrieden.
Oder was heißt besser zufrieden? Schlecht zufrieden warst du ja nicht, aber da warst du ein bisschen ausgelaugt vorletztes Mal. Schön, dass du den Freitag offensichtlich etwas anders genießen kannst.
Ja, vor allen Dingen brauchen wir jetzt einen positiven Abschluss. Wir haben im Vorgespräch uns gerade schon ein wenig geärgert über Microsoft zieht an, One Password zieht an, Confluence hat erhöht, Hetzner zieht an. Also rundherum merkt man halt, es zieht halt jetzt wirklich.
Ich habe letztes Jahr noch Festplatten gekauft. Ich glaube, das habe ich ziemlich schlau gemacht, dass ich im November letztes Jahr noch mal Festplatten gekauft habe.
Hättest du mal RAM gekauft. Pures Gold.
Ja, das pures Gold. Ich habe tatsächlich nach NVMEs hier liegen noch vier Stück mit 512 GB.
Also ich höre gerade, es wird ein Marketplace eröffnet. Gerne melden.
Ich glaube, die bringe ich jetzt mal zur Bank. Ich brauche die aktuell nicht. Ich würde die mal in den Tresor reinlegen.
Und sonst mal gucken, wie viel Bitcoins ich dafür kriege. Das ist echt crazy, was im Moment ist. Es ist eine verrückte Zeit.
Umso besser, wenn man zwar an wichtigen Themen drangeht, aber Podcast macht und auch Spaß mit der ganzen Nummer dabei hat. Über was wollen wir denn heute reden? Ich glaube, das geht fast auch so in die Richtung.
Ja, heute sprechen wir einmal über Incident Response. Also was im Ernstfall dann wirklich zählt, wenn etwas passiert.
Und wir gehen halt mal die Stufe weiter mit, im Notfall rufen wir die IT an. Das ist ja so was, der erste Tenor, der immer sagt, im Notfall rufen wir mal die IT an. Und wir gucken uns heute an, was das denn bedeutet und was IT bedeutet.
Und wer dann wirklich hinten dran hängt und was vielleicht noch gemacht werden sollte, bevor man die IT anruft.
Ja, und das schließt auch so ein bisschen an das Thema an, was du gerade zu Anfang gesagt hast. Was ist ein Incident? Da müsste man ja erstmal für sich diese Fälle festlegen.
Und ich glaube, du hast ja gerade gesagt, überall ziehen die Preise an und so. Auch so etwas kann ein ausschlaggebender Punkt sein, wo ich weiß, ich muss jetzt reagieren. Weil es jetzt utopisch wird, keine Ahnung.
Also das ist, glaube ich, erstmal so, wo man erstmal ran muss. Nehmen wir mal ein Beispiel. Montagmorgen 7.40 Uhr, 7.50 Uhr, egal. Buchhaltung meldet sich, hey, ich komme nicht auf den Feist-Server. Fünf Minuten später, zweiter Anruf, Produktion, Vertrieb, also dann zieht es sich so langsam durch.
Kurz später kriegst du dann auch die Meldung, ihr System wurde verschlüsselt, vielen lieben Dank. Und dann unten am besten noch gleich den Satz hin, wir melden uns bei Ihnen oder melden Sie sich bitte unter der Rufnummer und werfen Sie entsprechende Bitcoins ein.
Ja, genau. Und da merkt man halt, spätestens in diesem Fall oder an diesem Punkt, merkt man halt, habe ich mich darauf vorbereitet oder eben auch nicht. Wenn man nicht weiß, was jetzt zu tun ist, dann hat man sich wahrscheinlich eher nicht darauf vorbereitet.
Also wie gesagt, heute geht es um Incident Response und wie man sich vorzubereiten hat, ob man vorbereitet ist, das sind erstmal Dinge, die man zu klären hat. Michael, wenn wir über Incident Response sprechen, was denken da so die meisten Unternehmen?
Also der meiste Tenor ist so, ich sag mal, mach den Virus weg, also Virus entfernen, spiel ein neues Backup ein, fertig, weiter geht's. Das sind so die Themen, auch was wir ja eben oben kurz inszeniert haben mit, du hast einen Verschlüsselungstrojaner auf dem Rechner drauf und viele sind halt der Meinung, was ist da fertig, einfach einen Restore machen, den Virus runter und dann läuft die Marie weiter. Aber ich glaube, die Wirklichkeit sieht anders aus.
Ja, du hast es ja eigentlich gerade eingangs schon gesagt, es ist ja meist so, ruf mal die IT an. Und das ist eigentlich schon das größte Problem erstmal. Also in Wirklichkeit bedeutet es eigentlich wirklich, also wenn man jetzt davon ausgeht, du hast ja gerade gesagt, so wie es sich viele vorstellen, aber in Wirklichkeit, wenn jetzt wirklich so ein Incident stattfindet, dann bedeutet das eigentlich, ich muss erstmal Beweise sichern, Ausbreitung stoppen, also logischerweise vom Netz trennen und so, dann die Kommunikation steuern, dass ich sie unabhängig von diesem System schnell aufsetzen kann oder aufbauen kann oder in Betrieb nehmen kann.
So, ich habe mich am besten vorbereitet. Dann rechtliche Pflichten, also zum Beispiel, ich habe jetzt einen Vorfall, ich muss mich irgendwie an die Behörden wenden oder an meinen Datenschützer, den ich gerade eingesetzt habe. Und dann Geschäftsrisiken bewerben, ganz klar.
Also um dann wirklich feststellen zu können, was sind jetzt meine wirklich, also wo betrifft es mich jetzt genau und welche Auswirkungen hat es.
Ja und das halt unter Zeitdruck, das ist halt das Thema. Also bei all dem, wir kommen im späteren Verlauf noch dazu, wie man sich da am besten vorbereitet und was man mal machen soll. Aber du hast halt einfach das Problem, wenn es knallt, hast du halt Druck auf den Kessel.
Dann ist halt diese Spielereien vorbei mit jetzt müssen wir mal überlegen, was sollten wir denn und Kram, sondern eingetreten und du hast halt einen massiven Zeitdruck. Und das ist auch der Grund, warum in den ersten 60 Minuten, wenn das da so losgeht, so in den ersten Stunden, sehe ich halt bei vielen Leuten, das ist halt, ich nenne es mal vorsichtig die Chaosphase. Weil wenn die dann anfangen wie aufgescheuchte Hühner hin und her zu rennen und keiner weiß, was er tun soll, dann hast du ein tierisches Problem.
Und so ein typischer Ablauf ist halt eins, das erste ist halt, wie wir es schon anleitend gesagt haben, ich rufe halt mal die IT an.
Ja und da muss man ja auch ehrlich sein. Also warum ist es Chaos? Also zum einen, ja meistens, weil die Unternehmen ja nicht vorbereitet sind.
Sie wissen gar nicht, was da wirklich auf sie zukommt oder zukommen kann. Und weil sie ja nicht vorbereitet sind, haben sie auch keine Maßnahmen dafür. Und in den ersten 60 Minuten, dieses Chaos, was da entsteht und es ist wahrscheinlich sogar mehr als 60 Minuten, da ist es halt logischerweise so, die Mitarbeiter wissen nicht Bescheid, die wollen arbeiten, können aber nicht.
Können aber gar nicht einordnen, wie ist die Situation jetzt zu sehen. Dann, Geschäftsführung ist ja genau das Gleiche. Die sitzt dann, also die IT wird angerufen, die sitzt dann da und prüft quasi erstmal, ey, was ist hier gerade vorgefallen und so.
Man muss ja auch sagen, wann kommt die IT? Der sitzt ja, gut, wenn ich eine Abteilung bei mir im Haus habe, geht es natürlich schneller. Aber wenn ich einen externen Dienstleister habe, dann dauert das schon mal einen Augenblick.
Solange ist ja, ja, da ist ja gerade vogelfrei alles im Unternehmen. Dann kommt die IT, die prüft erstmal die Logs, um es einordnen zu können, um zu wissen, was sind jetzt die nächsten Schritte, um das lösen zu können. Und im Nacken sitzt einem dann die Geschäftsführung und fragt permanent, ey, wie schlimm ist es, wo stehen wir gerade?
Als ITler, ja, du bist ja noch dabei.
Ich wollte es gerade sagen, ich glaube, das ist so der Anfang von so einem ganzen Ding. Deswegen nachfolgend, was die IT am besten machen soll. Du hast halt das Problem, es brasselt als ITler halt einfach alles auf dich rein.
Die Mitarbeiter rufen dich an, die Telefonanlage noch funktioniert, ansonsten stehen sie bei dir an der Tür. Du brauchst eigentlich, nicht eigentlich, du brauchst als ITler Zeit und Muse, dir erstmal Gedanken zu machen, was ist, um ein Bild von der Lage zu kriegen. Damit du überhaupt einordnen kannst, was überhaupt passiert ist.
Und wenn du permanent irgendwelche Leute im Nacken sitzen hast und stehen hast, das mag keiner. Und dann kommt auch noch der Chef runter und macht noch und Kram. Und das ist so eine typische Sache.
Und deswegen muss man sich als ITler, man braucht ein strukturierendes Vorgehen. Man muss so einen Notfallplan, nenne ich es jetzt einfach schon mal, in der Schublade liegen haben, dass man strukturiert nach Sachen vorgehen kann. Und sein Programm runterspult und einfach sagt, bevor ich das jetzt nicht durch habe, machen wir hier erstmal gar nichts.
Ich kann es nicht ändern. Es ist halt so, aber ich brauche erstmal ein Bild von der Lage, um eine Aussage treffen zu können.
Und im Optimalfall, so wie du gerade gesagt hast, ich brauche einen Notfallplan in meiner Schublade. Es ist auch so, der Optimalfall ist so, dass der Notfallplan nicht nur im Unternehmen liegt, sondern auch beim IT-Dienstleister oder beim IT-Betreuer. Damit auch der die Vorgehensweise, die sich da mal irgendwann ausgemalt wurde, Bescheid weiß, wie das Ganze mal geplant war.
Es kann ja sein, dass man, warum auch immer, nicht den gleichen Mitarbeiter zu sich ins Haus bekommt, wie der, der es ursprünglich mal mit ausgearbeitet hat.
Ich gehe noch einen Schritt weiter. Dieser Notfallplan und diese Notfallkarte, lass uns da ruhig ein bisschen tiefer drauf reingehen, kurz an der Stelle. Der muss nicht nur beim IT-Dienstleister liegen, der muss auch definitiv auf einem anderen Ort liegen, wie auf einem Serverlaufwerk.
Das wäre praktisch, ja. Das ist halt der Klassiker. Die einen drucken ihn sich aus und legen ihn sich in die Schreibtischschublade.
Die nächsten machen, wo ich auch mitgehe, wo ich sage, easy, komm. Es gibt inzwischen, jedes Unternehmen hat in irgendeiner Art und Weise irgendwo noch eine Cloud liegen und hat irgendwie einen Zugriff drauf. Also wo ich hin will, an mindestens zwei getrennten Orten, die man zugreifen kann.
Jetzt kann man die Sache sagen, ja, aber wenn ich kein Internet habe, weil da irgendwie ein Problem ist, wie will ich dann auf die Cloud kommen zu meinem Notfallplan, sage ich immer, Leute, jeder wird ja wohl irgendwo ein Handy haben, wo du nochmal per Browser auf irgendein Cloud-Ding draufkommst. Ansonsten, wie du gerade schon reingeworfen hast. Das ist so sehr, wie ich Papier hasse an dieser Stelle oder so sehr, wie ich versuche, Papier zu vermeiden.
Aber das ist was, legt es euch vielleicht ausgedruckt irgendwo hin, dass es greifen kann.
Ja, mit dem Serverschrank, stört keinen, gehört genau dahin, ist der einfachste Weg.
Und was du parallel haben solltest, das ist vielleicht noch eingangs noch ganz wichtig, hänge auch Zettel aus, ganz klar, mit wichtigen Meldekontakten. Telefonnummern IT-Dienstleister, Notfallrufnummer IT. Vielleicht kombiniere es gerne, klingt blöd, ist aber vielleicht sinnvoll mit Polizei, Notruf, Feuerwehr, Durchgangsarzt, Datenschützer.
Danke, dass du es eingeworfen hast. Dass man so ein Blatt hat für die wichtigsten Dinge, für was passiert, wen rufe ich an. So eine ganz klassische Meldekarte.
Auch da im Praxisbetrieb kann das gerne auf dem Server liegen, kann das gerne in einem Unternehmens-Wiki drin sein. Aber so im Serverraum, vorm Serverraum, ausgedruckt an die Tür gehängt, vielleicht ein schwarzes Brett, was alle Unternehmen noch mit Sicherheit immer irgendwo noch haben. In der Kantine, neben dem Essensplan, irgendwo an zentralen Stellen dabei.
Dass wirklich es klar ist, wenn die IT im Extremfall komplett steht, ich immer noch die Möglichkeit habe einzusehen, wen kann ich kontaktieren und die, die ich kontaktiere, IT, Hashtag Notfallplan, zur Not wirklich im Serverraum oder an irgendeiner Stelle noch das Dokument finden, wo sie sich ein strukturiertes Vorgehen haben einfallen lassen. Das finde ich ist eine super wichtige Sache. Richtig.
Ja, und wo du es gerade sagst, strukturierte Vorgehensweise. Wir haben jetzt die letzten Wochen immer wieder mal darüber gesprochen. Michael, ich habe es technisch meist gesagt, hau raus, was hast du noch vor Augen?
An Sofortmaßnahmen, die du machen musst, wenn es losgeht. Das Erste, was du hast, ist als ITler identifiziere die betroffenen Systeme und isoliere die ganzen Sachen. Ich habe früher immer so meinen Running Gag gehabt, am Anfang, als wir angefangen haben mit Datenschutzschulungen und über die IT Security gesprochen haben, habe ich in Schulungen immer gesagt, zieht bitte das Netzwerkkabel aus den Computern raus.
Und wenn der Computer, wenn der komische Sachen macht, schon direkt an die Mitarbeiter. Wenn der Computer über WLAN ist, zieht bitte den Stecker raus aus den Computern. Auch immer wieder Running Gag, die haben mich, viele haben gelacht, ein paar haben verschwickts in die Ecke geguckt.
Ich habe immer gesagt, wenn ihr aus dem Monitor das Kabel rauszieht, ist der Bildschirm auch dunkel und es sieht aus, als wäre der Computer aus, aber es ist nicht der Computer aus. Also Spaß beiseite, wann immer noch der Computer ist, zu ziehen, bitte. Und da muss er auch nicht sauber runtergefahren werden oder sonst irgendwas, sondern raus.
Wichtig hier, Netzwerktrennung ist zu bevorzugen. Dann hat der ITler nochmal eine Chance reinzugreifen und zu gucken, wie das System ist. Manchmal, wenn du die Kisten ausziehst, kommt der IT-Forensiker und die IT-Schauern nicht mehr dahin, wo es eigentlich los war und hat ein Thema.
Wichtig ist, könnt ihr das Netzwerkkabel ziehen, trennt das System, isoliert die betroffenen Systeme und nennt die ganzen Dinge.
Im Umkehrschluss, genauso wie du gerade gesagt hast, Netzwerkkabel ziehen. Klar, wenn es per WLAN ist, dann die Netzwerkverbindungen kann man auch deaktivieren.
Ja, und im Zweifel halt raus. Notebook ausschalten. Im Optimalfall nicht abschalten.
Ja, aber lass uns das gerne diskutieren. Ich sage, es ist hier wie bei erster Hilfe. Du kannst nichts verkehrt machen.
Hauptsache, du machst erstmal irgendwas und die Priorität ist die Trennung von dem betroffenen System. Und bevor du jetzt eine Viertelstunde dir Gedanken machst, wie ich oben mein WLAN ein- und auskriege oder sonst irgendwas, halt am Notebook den Power-Button so lange gedrückt, bis das Ding aus ist. Zur Not, Priorität hat ganz klar die Isolierung und danach kommt erst die Aufarbeitung.
Wenn man sich aber vorher Gedanken gemacht hat, dann hat man da schnelle Wege für, um dann eben zum Beispiel WLAN und sowas zu deaktivieren.
Das ist Erwärmungsschulung. Das finde ich, das ist eine Erwärmungsschulung. Super Themen, wir können uns heute echt verrennen.
Das ist Erwärmungsschulung, wie ich meine Mitarbeiter für den Ernstfall trainiere und sensibilisiere. Das ist aber auch ein Stück weit, je harmonischer ich, wir hatten das schon mal auch in einem anderen Podcast, je harmonischer ich meine IT-Landschaft und meine IT-Struktur stehen habe, umso einfacher kann ich das vermitteln. Habe ich ein Kauderwelsch von unterschiedlichen Notebooks, unterschiedlicher Hersteller, Desktop-Rechner etc.
kriege ich sehr schwer nur vermittelt, an welche Workstation ich welche Maßnahme treffen muss, um das System sauber zu trennen. Habe ich aber mich geeinigt auf ein, zwei Notebook-Modelle oder ich weiß, sie sind alle nur noch über eine Dockingstation im WLAN-Kram und hast du nicht gesehen, kriege ich sehr einfach in die Mitarbeiter rein, weil ich nur ein, zwei Systeme schulen muss bzw. ich habe es einfach im Umfang und kann einfach sagen, drücke oben den Power-Button länger, bis das Ding aus ist.
Wer weiß, ob das alle Rechner so machen, wer weiß, ob die einen Computer haben, also Desktop-Station haben, die anderen Notebooks haben. Das heißt, je homogener ich meine IT-Landschaft habe, umso einfacher habe ich es für mich zum Schulen und umso einfacher haben es die Mitarbeiter zum Verstehen.
Ja, absolut. Ja, Isolation betroffener Systeme hatten wir gerade. Netzwerksysteme trennen, okay, das ist auch klar.
Oder Netzwerksegmente, das war ja noch spezifischer, was du gerade gesagt hast, wo man halt wirklich ganze Netzwerkteile einfach rausnimmt. Damit ist sichergestellt, dass alle nicht mehr ins Internet kommen, nicht weiter kommunizieren können und vor allem auch andere Netzwerkbereiche nicht infizieren. Kann man nicht ausschließen, aber so hat man zumindest schon mal etwas in die Richtung gemacht, damit es nicht, falls es noch auf diesem System nur war, in Anführungsstrichen nur, dann geht man dem aus dem Weg, dass andere Systeme halt auch befallen werden.
Ja, ganz genau.
Danach logischerweise Admin-Zugänge sperren. Versteht sich, denke ich, von selbst. Von irgendwo muss es ja dann kommen.
Und ja, um da der Gefahr auf jeden Fall aus dem Weg zu gehen, dass die Angreifer wirklich die Systeme noch komplett übernehmen und ich nachher selber kaum noch Zugriff darauf habe, auf jeden Fall sperren.
Ja, gut, dann solltest du so langsam mal gucken. Also das wäre so das, was ich als erstes machen würde. Wenn ich da schon mal so, das sind so die Basics, die wir gerade getrieben haben, wo ich sage, ich isoliere den ganzen Kram, ich mache mir mal Gedanken um meine Zugänge.
Dann wäre das Nächste, was ich als Dealer machen würde, ich würde mal rüberluren auf meine Backup-Systeme und würde mal gucken, was da so passiert und was da so gemacht ist. Laufen die noch in einem vernünftigen Zustand? Sind die noch in Ordnung, sind die safe?
Wann haben wir das letzte Backup? Hat vielleicht die Verschlüsselung ins Backup schon eingegriffen? Das wäre so das Erste, das ich mal da prüfen würde.
Das heißt nicht, dass ich sofort in den Restore gehe, sondern das heißt, ich prüfe einfach mal den Zustand meiner Backup-Systeme. Das wäre so das, was ich machen würde.
Warum nicht direkt in Restore? Das kann ich vielleicht auch technisch dann nochmal einmal darlegen. Es ist halt so, wenn wir jetzt anfangen würden, wir haben jetzt drei Systeme, die sind befallen.
Das ist ein Netzwerkssegment, wie wir vorhin gesagt haben, meinetwegen die Buchhaltung. Der Rest wäre jetzt noch nicht betroffen, also zumindest nicht offensichtlich betroffen. Dann könnte ich jetzt herangehen und sagen, okay, ich mache einen Restore auf diese drei Systeme, würde die wieder ganz normal ans Netz bringen, und dann hat es sich aber doch auf die anderen Systeme mit ausgebreitet.
Das heißt, ich habe eigentlich nichts gewonnen. Ich muss ja erstmal die Ursache finden, oder beziehungsweise erstmal wirklich eingrenzen können, wo ist es jetzt gerade aktiv. Weil ansonsten mache ich den Vorgang mehrfach.
Ich verliere Zeit, um wieder wirklich produktiv zu werden. Also da muss man auf jeden Fall erstmal feststellen, okay, sind jetzt die Systeme, die ich offensichtlich noch nicht infiziert habe, ist da wirklich nichts? Wenn da nichts ist, okay, ab da.
Oder man kann auch noch anders herangehen, dass man sagt, okay, diese drei Systeme, die habe ich ja isoliert. Ich würde den Restore laufen lassen auf diesen drei Systemen, aber die lasse ich noch nicht zurück in Kontakt mit den anderen Systemen, sondern das läuft dann parallel. Also die habe ich wieder am Laufen und die anderen kann ich noch prüfen.
Also das ist auch, muss man sich vorher mal Gedanken drum machen, wie da der optimale Weg ist. Und vor allem ist es auch abhängig, welche Systeme sind befallen. Wenn es zentrale sind, ist das Thema eh durch.
Vor allen Dingen sind wir ja jetzt noch in den Sofortmaßnahmen drin. Und ein Backup wieder herzustellen, gehört auf gar keinen Fall in die Sofortmaßnahme rein. In der Sofortmaßnahme machst du so einen Augenblick drüber auf, wie sieht denn mein Backup-Server aus und guckst da rein, weil sich danach ja entscheidet, wie das weitere Vorgehen ist.
Aber auf gar keinen Fall fängst du in der ersten Stunde, in den ersten zwei Stunden an, ich komme aber auch gleich noch zu, was viele Unternehmen falsch machen. Du fängst auf gar keinen Fall da an, wild, hektisch, vielleicht im Affekt, irgendwelche Restores einzuspielen nach dem Motto, lass mal schnell das Ding wieder ans Rollen bringen, vielleicht kann ich die Nummer klein halten. Das Kind an sich liegt im Brunnen.
Wir haben die Isolation und alles vorgenommen, wir gucken uns das konzentriert an und dann folgt eine kontrollierte, vernünftige Aufarbeitung, Ursachenanalyse und das gefolgt von einem vernünftigen Wiederanlaufplan. Das muss strukturiert sein, sonst machst du mehr kaputt, wie alles wäre. Ich glaube, das hat jeder von uns, zumindest ich habe das schon mal gehabt, das hat jeder von uns schon mal gehabt, dass du bei der IT ein Problem hast und du denkst, komm, ich mache mal schnell hier, ich ändere da mal schnell was, ich baue mal da schnell neue Hardware rein, ich ziehe mal schnell da die Platte raus und stecke die wieder.
Du kannst mit Schnellaktionen, die unüberlegt sind oder im Affekt passieren, noch viel mehr kaputt machen, wie du es vorher schon gemacht hast.
Michael, ich wollte es auch nur unterstreichen mit dem, was ich gesagt habe. Backups irgendwann wieder einspielen ist richtig, aber nicht zu diesem Zeitpunkt, weil man noch gar nicht richtig eingeordnet hat, wo man gerade steht. Ganz genau.
Da haben wir letztes Mal auch so ganz kurz drüber gesprochen, weil wir ja auch keinen Supply Chain Angriff auslösen wollen, stoppen wir bitte auch die externe Kommunikation.
Das ist, denke ich, ein ganz wichtiger Punkt. Ich glaube auch, denn den Kettenbrief geben wir nicht weiter.
Genau, aber das ist ja auch wirklich eine Riesengefahr. Ich meine, am Ende des Tages könnte man jetzt sagen, ja gut, ich habe einen Angriff, dann haben die halt auch einen Angriff. Aber was heißt das denn nachher auch reputationsmäßig und so weiter?
Hängt schon eine Menge dran. Deswegen, da muss man auch entsprechend so viel Verantwortung zeigen, dass man sagt, okay, wir klinken uns jetzt hier aus und wir melden uns dann, wenn es soweit ist. Oder auf einem anderen Kanal, um mal eben eine Info rüberzugeben, aber wirklich systemisch da jetzt erstmal einen Cut zu machen und zu sagen, okay, wir melden uns, wir haben gerade andere Probleme.
Genau, wir arbeiten im Moment. Irgendwann hatte ich mal so einen Anrufbeantworter-Text, den habe ich irgendwo bei einem Unternehmen angerufen. Wir können Ihre Anfrage gerade nicht beantworten.
Wir arbeiten an größeren Problemen als Ihres. Da wusstest du genau Bescheid. Die lässt du jetzt mal die nächsten drei, vier Tage alleine und dann versuchen wir wieder reinzukommen.
Aber das ist mal eine geile Ansage, muss ich sagen. Ich meine, das ist schon Ewigkeiten her. Ich war bei irgendeinem Ami, irgendeinem Ami angerufen und die haben echt aktuell jetzt nicht, wir haben anderes zu tun.
Aber da kommen wir nahtlos zu diesen Punkten, was Unternehmen so am Anfang immer so falsch machen, was mir so auffällt, wo wir sagen, das ist so dieses, wo ich die meisten Probleme sehe oder was so häufige Fehler sind, die Unternehmen treiben. Für mich ist das Erste ganz klar, die lassen die ITler alleine. Also es ist ein IT-Problem, es ist ja ein Angriff auf die IT.
Die IT ist verschlüsselt oder die IT ist kaputt. Die IT funktioniert im RZRPP. Das wird sich der ITler schon machen.
Wir nerven den zwar, aber an sich lassen wir ihn mit der Arbeit alleine. Und das, finde ich, ist definitiv der falsche Ansatz. Und das ist so der erste Fehler, der ursächlich gemacht wird.
Ja, das ist so. Also das muss ein Hand-in-Hand-Ding sein, ganz klar. Ja, nehmen wir den Punkt nochmal auf, den du gerade, wo du den Ball hochgespielt hast, Backups sofort wieder einspielen.
Ja, Logs werden ja dabei direkt überschrieben. Das heißt, ich kann die Ursache gar nicht mehr nachvollziehen. Das, finde ich, ist auch immer so ein Riesenpunkt.
Und im besten Fall bist du als IT-Dienstleister zum ersten Mal bei diesem Kunden, weil jetzt gibt es ja zum ersten Mal ein Problem und dann gibt es nicht mal eine Dokumentation. Also das ist auch so ein Punkt, wo ich immer sage, boah, schwierig. Also ich weiß gar nicht, was hier gerade los ist.
IT, okay, jetzt, ich will nicht jammern, so soll es nicht klingen, aber es ist einfach so, also IT, man mag von außen aber denken, okay, da steht ein Server, da sind fünf Rechner angeschlossen, ist immer das Gleiche. Die Verbindungen unter diesen Systemen, die virtuell passieren, die ich von außen nicht sehen kann, wie soll ich die kennen? Das kann ich mir nicht aus den Fingern saugen.
Das kann ich systemisch sehen oder ich habe es in der Dokumentation. Also deswegen, das ist halt oft ein Problem. Wenn es keine Dokumentation gibt, stehst du echt ziemlich blank da.
Thema Dokumentation, wenn wir bei dem Notfall, wir waren eben bei so einem Notfallhandbuch, haben wir schon mal in den Raum geschmissen und wir waren bei so einer Karte mit den wichtigsten Telefonnummern. Für mich ist wichtig an der Stelle nochmal, es sollte von Beginn an auch eine weitestgehend lückenlose Vorfallsdokumentation stattfinden. Gerne echt auch wirklich, wenn wir schon bei ausgedruckt, gerne schreibt es auf irgendein Papier rauf, wo so die wichtigsten Fragen, die ich mir vorher überlegt habe, die ich wissen will, da schon mal mit reinmachen.
Was ist passiert? Wann ist der Vorfall passiert? Wer hat ihn zuerst erkannt?
Wer hat an wen gemeldet? Welche Schritte sind eingeleitet? Ist der Datenschützer informiert?
Ist der ISB informiert? War die Geschäftsleitung vorbei? Also, dass du eine lückenlose...
Wie wurde es gelöst und wie sind die Learnings? Noch nicht mal, da kommen wir gleich...
Gehört für mich aber mit rein.
Ja, aber selbst für die nächsten Schritte musst du ja erst mal wissen, wie es losging. Und wenn du am Anfang schon die Systeme alle wegnimmst und machst den ganzen Kram, musst du es schon dokumentiert haben. Also auch das, wenn wir nachher über den Wiederanlaufplan reden und machen uns Gedanken darüber, wie wir die Systeme wieder hochfahren und wieder in Normalbetrieb gehen, muss ich ja vorher wissen, was habe ich denn getan, aus dem Normalbetrieb, den ich hatte, was habe ich denn gemacht?
Welche Serververbindung habe ich gehabt? Welche Netzwerke habe ich segmentiert? Was habe ich getan?
Wenn ich mir das nicht dokumentiere, wenn ich mir das nicht irgendwie, und wenn es auf dem Schmierzettel ist, in irgendeiner Art und Weise mitschreibe, und da bin ich halt ein Freund davon, irgendeine Vorlage zu verwenden, dass ich weiß, was mich erwartet, damit ich nicht überlegen muss, was muss ich denn jetzt noch dokumentieren, sondern dass ich einfach weiß, so wie so 5 W-Fragen, dass ich genau weiß, wo hänge ich denn, was mache ich denn, dass ich das aufschreibe. Sonst verliere ich mich im Chaos und ich kriege die Systeme nachher nicht mehr hoch und ich kann nachher, wenn es wirklich weitergeht, Datenschützer ist im Boot, wegen mir kommen die Polizei noch, irgendwelche IT-Forensiker kommen, der IT-Dienstleister von draußen kommt rein, die fragen alle, wann ging es denn los, was ist denn passiert, wie haben sie es erkannt und was haben sie bis jetzt getan.
Das sind so diese typischen Dinge und das muss ich aufschreiben. Und wenn ich das nicht aufgeschrieben habe, kriege ich das an einem halben Tag oder in einem Tag nicht mehr zusammen. Das ist, finde ich, eine super wichtige Sache zum Thema Dokumentation.
Ja genau, für mich ging es, also weil du gerade gesagt hast, Vorfalldokumentation, für mich ist auch wichtig, dass da vielleicht auch schon drinsteht, so wurde es beim letzten Mal gelöst. Du hast recht klar, die Ursachen oder die einleitenden Schritte müssen dokumentiert sein. Ich finde aber auch, wenn die Schritte, also auch bis zur Lösung der ganzen Sache, wenn die mit dokumentiert werden, ist das super hilfreich.
Wenn jemand dann nochmal neu anfängt, dann... Das hast du im Notfallhandbuch.
Im Notfallhandbuch hast du drinstehend...
Kennst du es tatsächlich selber?
Also ich persönlich würde beides miteinander kombinieren in einem Ordner. Ja, ein Ordner, aber es ist ein anderes Dokument, es ist ein anderer Inhalt. Du hast ein Blatt.
Ja, ja, das ist doch okay.
Du hast ein Blatt und wegen mir, wenn du das richtig ausarbeitest, kannst du da noch ankreuzen, folgende Fehler sind bereits im Notfallhandbuch beschrieben und dann schreibst du das in der glatte Runde und dann kannst du es ankreuzen und was es geht und dann hast du sofort den Input ins Notfallhandbuch. Aber im Notfallhandbuch beschreibst du welche Maßnahmen du machst, um das Ding wieder anzulaufen, wieder anlaufen zu lassen. Bekannte Ursachen, wo es dran schon mal liegen könnte, das beschreibst du ganz klar in deinem BCM und in deinem Notfallplan.
Da sehen wir wieder, du bist Datenschützer, Papierfuchs. Es muss irgendwo stehen.
Ich bin ja schon glücklich, wenn es irgendwo steht.
Michael, nur kurz zur Erklärung. Deswegen haben wir uns gerade auch missverstanden. Für mich ging es darum, ich komme ins Unternehmen und da habe ich jetzt einen Ordner stehen, da steht das alles drin.
Mein Vorfallmanagement oder meine Vorfalldokumentation und genauso auch meine Notfalldokumentation. Für dich sind das zwei völlig unterschiedliche Paar Schuhe.
In Wirklichkeit sind es fast fünf. Wenn ich fertig bin, sind es fast fünf, aber ja.
Ja, aber wenn ich als Externer reinkomme und das Problem lösen soll, brauche ich es an einem Ort. Darum ging es mir in einem Ordner, wo klar sind das unterschiedliche Dokumente, aber sie hängen ja irgendwie miteinander zusammen. Und deswegen wäre es für mich als Dienstleister extrem hilfreich, wenn ich weiß, okay, ich mache den Ordner auf, da habe ich das, da kann ich nachgucken, wie wurde es beim letzten Mal gelöst und was weiß ich was.
Ich hoffe, das hat man nicht so häufig, dass man die letzten Fälle nachlesen kann und den gleichen Fall wieder hat. Aber wenn es so wäre, dann hat man auf jeden Fall da schon mal so ein bisschen Möglichkeiten. Das unterstützt den Vorgang einfach.
Und wenn wir bei dem Ordner gerade sind, dann reiten wir noch ein Stück auf dem Ordner weiter. Der Ordner sollte aktuell sein. Also an alle, die die IT-Dokumentationen, ja, nee, ja, aber...
Das predigen wir jetzt seit zwei Jahren.
Ja, aber wir predigen, dass das auf dem Server vernünftig ist und dass es überhaupt eine aktuelle Doku gibt. Aber wenn ich die Doku gerade ziehe in irgendwelchen Softwaresystemen, auf irgendwelchen Netzlaufwerken, in irgendwelchen Dokumenten, sollte ich halt nach der Freigabe irgendwann einen Input kriegen oder einen Impuls kriegen. Prüf mal die Aktualität des Notfall, des ausgedruckten Notfallordners im Serverraum, um es konkret mal in Worten zu benennen, dass ich sage, tonosmäßig einmal im Jahr, einmal im halben Jahr gucke ich mir den an und gleiche das, was da ist mit meiner aktuellen IT-Dokumentation, die ich auf Netzwerken oder irgendwelchen Systemen getroffen habe, ab, um zu gucken, ob das noch gleich ist.
Und vor allem Learnings berücksichtigen.
Ja, da gehört dann halt auch die Netzwerklandschaft dazu, dass ich einfach sehe, wo kommt was rein, wo ist mein Übergabepunkt, wo sind Firewalls, wo sind Kram und wie finde ich das und wie sind die benannten. Das finde ich...
Gerade im Notfallhandbuch sollten neu angeschaffte Systeme und sowas auch bitte berücksichtigt werden.
Ja.
Ja. Unterschreibe ich sofort.
Genau. Aber du musst halt auch denken, ich meine, ich bin halt ziemlich viel digital unterwegs. Deswegen, wenn ich bei Kunden, wenn wir über Notfallhandbücher reden, reden wir über BCM, gehen wir immer Asset-basieren.
Das Asset-Inventar ist natürlich immer aktuell gepflegt im System. Aber du musst halt irgendwann dran denken, mach mal einen Export, mach mal einen Ausdruck, hol dir mal das Wichtigste. Auch wirklich in dein zweites System rein als Backup-System, wenn das erste System ausfällt.
Sprich, wo wir uns hier gerade darauf geeinigt haben, auf deinen Ordner im Serverraum. Der muss halt auch aktuell sein.
Ja, im Serverraum oder bei uns oder was weiß ich.
Egal.
So, dass es vorliegt und Zugriff darauf ist.
Nennen wir es mal pauschal die Duplette. Weil, wo die liegt, ist was anderes, aber die Duplette an sich sollte der Realität sein. Richtig.
So, kommen wir zurück zur eigentlichen Frage. Beziehungsweise Frage ist falsch.
Zu den Fehlern. Warte, kleiner Spaß. Nur ein kleiner Spaß am Rande.
Also kein Spaß. Bei uns im näheren Umkreis hat es jetzt leider brandtechnisch ein Unternehmen erwischt und der Brand ging im Serverraum los. Also so viel zum Thema Notfallhandbuch im Serverraum.
Wobei die, glaube ich, andere Probleme hatten wie das Notfallhandbuch zu greifen. Ja, also selbst, aber auch das. So viel Spaß oder so viel Ernsthaftigkeit, wie es dranhängt.
Ein Notfallhandbuch dazu liegen zu haben, wo die Daten liegen. Also, du hast einen Server, da liegen deine Daten und in dem gleichen Raum befindet sich auch das Notfallhandbuch. Taktisch machbar in der Risikobetrachtung wäre vielleicht ein anderer Ort noch besser geeignet.
Ja, ist immer die Frage, welche Risiken man alle berücksichtigt. Ja, das hast du natürlich recht.
Okay, weiter geht's.
Gut. Ich würde sagen, nächster Punkt, bei dem, bei den häufigsten Fehlern ist sicherlich auch externe Unterstützung zu spät dazu zu holen. Wo sich Unternehmen vielleicht auch die Ernsthaftigkeit des Problems nicht eingestehen wollen.
Die da am besten noch selber irgendwie Hand anlegen und gucken, das schaffen wir schon. Das ist ja, ich installiere hier irgendwas und fertig.
Klassisches Kapitel im Notfallhandbuch. Also ich drück's mal ganz pauschal und salopp aus und dann kann man in Details reingehen. Die Situation des IT-Notfalls bewertet der Punkt, Punkt, Punkt.
Herr, Frau, Punkt, Punkt, Punkt ist berechtigt, Sofortmaßnahmen in Höhe von Punkt, Punkt, Punkt Dollars einzureichen, ohne Rücksprache mit der Geschäftsleitung und entsprechende Maßnahmen zu treffen. Also es muss klar sein, wer, wenn so eine Meldung reinkommt, sich den IT-Vorfall greifen und bewerten kann und der muss in der Lage sein, direkt und ohne Passierschein A38 mit einer Bestellanforderung in dreifacher Ausfertigung, irgendwelche Experten extern dabei zu holen. Klingt lustig, ist aber in vielen Unternehmen echt so die Sache, wo man sagt, ich würde jetzt schon gerne Experten holen, frage ich jetzt den Chef, frage ich den Einkauf, was mache ich?
Und auch das, klassisch Notfall, den Experten, den ich da gerne hätte, den suche ich mir im Vorfeld aus, damit ich die Telefonnummer von dem habe und habe die Kontaktdaten und kann den anrufen und dann kann der aktiv werden. Und dann mache ich mir vorher mit meiner Geschäftsführung, mit meinem Unternehmen, werde ich mir klar, einer hat einen Holdauf, der darf entscheiden, wird der jetzt kontaktiert, also hole ich Experten, ja, nein und auch gleichzeitig, ich darf das tun, ohne mir vom Einkauf oder vom Geschäft oder irgendeinen Segen abzuholen. Oder es muss klar kommuniziert sein, werden Experten gebraucht, ist der anzurufen, der entscheidet über Budget, der gibt frei, da hängt eine Notfallrufnummer dabei, der ist immer erreichbar, etc.
Das muss sauber klar sein, weil das sind echt die falschen Gründe, keine Experten oder zu späten Experten dabeizurufen, wenn es wirklich organisatorische Sachen sind.
Und du hast gerade einen wichtigen Punkt gesagt, über den haben wir auch schon mal gesprochen, holt euch Partner in guten Zeiten dazu, nicht im Stressmarkt. Immer, immer. Also dann vorher, das gehört mit zur Planung, wen betraue ich jetzt mit gewissen Aufgaben, wenn jetzt mal was vorfallen sollte, dementsprechend immer in guten Zeiten machen, dann findet man auch passende Partner.
Ganz wichtig.
Das ist eine wichtige Sache.
Ja, dann glaube ich, was auch meiner Meinung nach sicherlich ein Thema ist, ist öffentliche falsche Aussagen. Also wirklich das Thema vielleicht nach außen hin runterspielen, so tun, als wäre eigentlich fast nichts passiert, so ungefähr. Also man sollte da schon transparent sein.
Ich meine, Cyberangriff ist jetzt nichts, nichts in Anführungsstrichen außergewöhnliches in der breiten Masse, so muss man das sehen für das Unternehmen, in dem Augenblick schon natürlich. Aber es ist jetzt nichts, wo das Unternehmen selbst eine Schuld trägt, vielleicht je nachdem, wie der Angriff stattfindet. Aber darauf brauchen wir aber jetzt nicht weiter ein.
Aber grundsätzlich ist es etwas, womit man nicht hinter Berg halten muss und so tun muss, als wäre es nicht passiert.
Wir rattern heute einmal Krisenstabhoren runter. Ein Kommunikationsplan liegt mit im Notfallhandbuch. Im Notfallhandbuch ist definiert, wer in Krisensituationen, also bei solchen Sachen, die externe Kommunikation übernimmt.
Und das ist, sorry, wenn ich das so sage, wahrscheinlich eher nicht geeignet der ITler, vielleicht eher nicht die Geschäftsleitung und vielleicht eher nicht, echt sorry an alle, die Dame vom Empfang, sondern ich habe mir in meinem Notfallhandbuch eine Krisenkommunikation festgelegt, mit Kunden, mit Behörden, mit Staatsanwaltschaft, mit etc. pp und habe da eine Person benannt, die in der Lage ist, dass, wie du das eben gesagt hast, offen, transparent, abgestimmt, professionell zu kommunizieren. Hashtag Marketingabteilung.
Zum Beispiel, ja. Zum Beispiel, aber halt, wie gesagt, abgestimmt, weil das muss passen, das muss vernünftig sein, das muss offen sein, das muss ehrlich sein, das muss nicht überzogen sein, das muss eine vernünftige Außenkommunikation sein und es muss auch klar geregelt sein, nur diese Person kommuniziert mit außen. Weil, geh mal in andere Unternehmen und das ist gar nicht so weit weg, wie schnell bist du ein relativ großes KMU oder ein KMU, was im näheren Umkreis ist, wenn das bekannt wird, dass du einen Cyberfall hast, da fragt dann schon mal die Polizei an oder da ruft dann schon mal die Presse an und dann telefonieren schon mal Kunden mit irgendwas und dann darf halt nicht oder sollte nicht jeder irgendwas nach draußen geben, jeder irgendwas sagen, sondern es gibt eine Kommunikationsschnittstelle, an die wird grundsätzlich verwiesen und die gibt Informationen nach draußen, die abgestimmt sind und die in Ordnung sind.
Die darf vielleicht auch gar nicht alles nach draußen geben, wenn es laufende Verfahren sind, wenn die Staatsanwalt mit dabei ist etc. pp. Man will vielleicht auch gar nicht, dass es nach draußen geht, weil es vielleicht andere Themen noch gibt.
Also ganz wichtig, einer der häufigsten Fehler ist unklare Regeln.
Nicht lügen oder es runterspielen. Ich gehe den Weg mit, dass man nicht sofort mit allen Informationen rausgeht, weil man gewisse Dinge sicherlich noch zu klären hat oder einfach für sich selbst erstmal. Nein, nicht für sich selbst.
Das ist so, wie ich vorhin gesagt habe, um erstmal die Situation genau einschätzen zu können, da hat man erstmal ein bisschen was zu tun, deswegen geht man nicht mit allen Informationen sofort raus, aber grundsätzlich braucht man nicht so zu tun, als wäre nichts oder gar falsche Behauptungen aufzustellen. Das wäre natürlich eine Katastrophe.
Genau deswegen ist in meinem Notfallhandbuch für die externe Kommunikation ein Ansprechpartner drin, der bei der Erstellung des Notfallhandbuchs ein Teil des Krisenteams ist, was ich definiere, der ist mit dabei, der weiß, was er macht und er weiß, was er tun soll und er stimmt sich mit den anderen Beteiligten ab und das ist die Schnittstelle. Zu vermeiden gilt, jeder gibt irgendwas nach draußen unabgestimmt, weil dann hast du nämlich genau das Risiko, was du gerade beschrieben hast, der ITler wird so nerdig, die anderen sagen vielleicht, vielleicht ist es besser, sagen wir mal, es wäre nett so und spielen die ganze Kiste runter und das kommt mit einem Bummerang zurück. Deswegen Kommunikation nach extern, verantwortliche Person festlegen, im Handbuch definieren, klare Meldewege etc.
pp. Gilt übrigens genauso auch für innere Kommunikation.
Ja, absolut. Also wenn wir jetzt einfach mal gucken, wer muss denn informiert werden in dem Fall, wenn sowas passiert? Also du hast es gerade gesagt, klar, man hat sich vorher ja den Plan gemacht, aber es gibt auf jeden Fall Punkte, die sollte man auf jeden Fall ansprechen und informieren.
Also Geschäftsführung, klar, das erklärt sich, denke ich, von selbst. IT-Leitung, ja, wenn er in dem Augenblick nicht da ist, hab bitte auch da die Info hin. Das ergibt sich ja auch von selbst.
Datenschutzbeauftragter hatten wir vorhin gesagt. Immer gerne. Gerade wegen der Meldung an die Behörden usw., um das nochmal genau eingrenzen zu können und uns richtig zu melden. Aber da muss man auch schnell sein. Wir hatten ja zum Beispiel über diese 72 Stunden, glaube ich, gesprochen. Genau.
Die man da einzuhalten hat. Ja, Cyberversicherung, logischerweise, die darf man auch nicht zu spät in Kenntnis setzen, dann steht man nämlich auch ziemlich blank da. Externe Forensik, ja, ist klar, die sollen mich ja unterstützen.
Dementsprechend muss man sich da auch melden. Ja, und dann Behörden, das hatte ich ja gerade gesagt, entweder direkt oder eben zum Beispiel über den Datenschützer oder eben über den Kommunikationsweg, den man da hat und wie du gerade genau dargestellt hast. Also ich fasse das mal zusammen.
Kunden, Öffentlichkeit, dass die halt entsprechend Kunden vielleicht noch mit ein bisschen mehr Informationen als die Öffentlichkeit, weil die Kunden ja auch ungefähr wissen müssen, wann man vielleicht, wenn man es einschätzen kann, wieder am Start ist oder ob sie selber vielleicht auch eine Gefahr sehen müssen, wie auch immer. Also das sind auf jeden Fall aus meiner Sicht die Leute, die müssen informiert werden. Das ist einfach, das gehört dazu.
Das sind ja alle irgendwie auch betroffen.
Ja, richtig ist da noch mal kurz Bestätigung, genau. 72 Stunden, wenn es Datenschutzvorfälle sind, 72 Stunden, jetzt komme ich wieder zu den Checklisten oder zu dem Blatt, was ich am Anfang gesagt habe. Wenn ich weiß, wann das Ereignis eingetreten ist, weil ich es dokumentiert habe, kann ich auch sagen, wann die 72 Stunden laufen.
Da wird mir jetzt plus minus eine Stunde keiner von der Behörde oder so einen Strick drehen, aber grundsätzlich muss ich wissen, wann ein Ereignis eingetreten ist, damit ich auch entsprechende Meldefristen entsprechend ab diesem Ereignis laufen lassen kann. Deswegen ist es wichtig zu erfassen, wann es da ist und deswegen ist es auch wichtig, rechtzeitig und frühzeitig den Datenschutzbeauftragten mit reinzuholen. 72 Stunden sind halt 72 Stunden, aber es sind halt auch nur 72 Stunden.
Richtig, ja. Ja, und du hattest gerade gesagt, interne Kommunikation, also da ist auch wichtig, keine Panik verbreiten. Wenn da jemand wirklich losrennt oder keine Ahnung was hier los ist und dann auf der anderen Seite sollen dann die Mitarbeiter oder alle, die ja irgendwie von betroffen sind, sollen dann da ruhig und locker mit umgehen.
Schwierig. Dann keine Gerüchte, das ist das, was ich gerade sagte, keine Unwahrheiten oder so, nur das, was wirklich klar ist, was wirklich Hand und Fuß hat und klare Anweisungen. Richtig.
Es sind nicht alle in meinen Notfallplan eingeweiht. Also die haben nicht alle das gleiche Wissen und das müssen sie auch nicht. Brauchen sie auch nicht.
Genau, es ist ja an der Stelle vereinbart, okay, wenn der Krisenfall eintritt, dann ist das die Person, die sich darum kümmert, um die interne Kommunikation und die da auch die Anweisung gibt, wie wir jetzt gerade verfahren. So, und dann wird diese Person sich darum kümmern und zwar wirklich mit klaren Anweisungen, damit eben dieses Chaos, was wir vorhin angesprochen hatten, was zu Anfang sicherlich herrscht, damit sich das beruhigt. Weil am Ende des Tages haben die Mitarbeiterinnen und Mitarbeiter, die da im Unternehmen sitzen, gerade ja keinen Einfluss darauf.
Das heißt, die muss man erstmal ein Stück weit beruhigen und sagen, okay, komm, ey, wir sind da dran, mach du dir jetzt erstmal keine Sorgen, wir kriegen das schon hin, so ungefähr. Also man muss halt, und dann wirklich dann im Anschluss zu sagen, okay, und das macht ihr jetzt, was weiß ich, zum Beispiel, sagen wir mal, du hast eine Mitarbeiterin, die einen klaren Draht zu Kunde XY hat. Dann kann es auch sein, dass man sagt, okay, hier, du geh mal los und sprich mal bitte mit denen.
Wenn es abgestimmt ist, ja. Wenn es abgestimmt ist, ja, ja, meine ich ja. Deswegen, das ist ja die Anweisung, die kommt.
Aber grundsätzlich, also es geht einfach darum, dass sie die Anweisung bekommen, weil sie eben an der Stelle dann die Sicherheit von dem Team bekommen, was eben diese Maßnahmen ursprünglich auch mal ausgearbeitet haben.
Und ansonsten können die meisten Mitarbeiter an der Stelle erstmal eh nichts helfen. Geht heim. Die Kaffeemaschine ist nicht betroffen.
Ich wollte es gerade sagen, also das ist halt so, das ist halt passiert. Ja, okay. Aber wir haben jetzt schon, guck mal auf die Uhr, wir haben schon ziemlich viel immer über Notfallplan und Notfallthemen gesprochen, jetzt in den letzten 40 Minuten.
Lass uns das mit diesem Notfallplan, mit diesem Notfallhandbuch nochmal kurz zusammenfassen, dass das klar ist, was wir uns vorstellen, was mindestens in so einem Buch drin sein sollte. Ja, dass wir da nochmal ganz kurz abholen und da nochmal kurz eine Struktur reinkriegen. Ich finde das Erste, was wichtig ist, ist, du brauchst klare Rollen und Verantwortlichkeiten.
Für die IT ist verantwortlich, das Notfallteam setzt sich zusammen aus, für die Kommunikation ist verantwortlich und bei Verantwortlichkeiten auch ganz klar, auch da schon rein, was sie tun sollen und auch gerne, wir hatten eben das mit Budgets und wer darf wen anrufen, auch gerne die Befugnisse. Also steckt da gerne ein bisschen Hirnschmalz rein, pumpt das ein bisschen auf und sagt nicht einfach nur, es gibt ein Notfallteam, was sich zusammensetzt aus Müller, Mayer, Schulze, sondern schreibt ruhig rein, das ist der für die Kommunikation verantwortliche Person, folgende Verantwortlichkeiten, folgende Befugnisse. Dass klar ist, was da drinnen dran ist und da gehört auch rein, wer den Notfall auslösen darf, also wer das ganze Ding in Kraft setzt, wer entscheidet, es ist jetzt wirklich ein Inzident und wer auch nachher entscheidet, das Ding ist jetzt wieder fertig, wir machen jetzt hinter diesem Vorgang mal einen Haken, lassen es lören, es ist alles abgeschlossen, Häkchen dran, es läuft wieder alles, Krise aufgehoben.
Also das sind so Dinge, wo ich finde, das ist super wichtig, dass das über Rollen und Verantwortlichkeiten klar ist. Definitiv.
Michael, Eskalationsstufen ist, glaube ich, auch klar. Ja, ich meine, da haben wir auch im Notfallbereich, also als wir über das Notfallmanagement gesprochen haben, sind wir da ja drauf eingegangen. Also Eskalationsstufen ist klar.
Also es gibt ja unterschiedliche Fälle, dann an welcher Stelle stehen wir in diesem Fall. Also ich sage mal, wenn du jetzt erst mal feststellst, okay, ich habe ein Virus auf dem Einzelrechner, okay, wobei heutzutage hört man das eigentlich gar nicht mehr groß. Aber nehmen wir mal an, es wäre so, dann hast du natürlich einen kleinen Vorfall, in Anführungsstrichen klein.
So, wenn du dann aber im nächsten Augenblick merkst, okay, jetzt irgendwie breitet sich da gerade was im Netzwerk aus, da muss da auch jemand stehen, der sagt, okay, und jetzt gehen wir die Eskalationsstufe hoch, weil jetzt sind wir in einer ganz anderen Situation. Deswegen müssen die auch mit niedergeschrieben werden, was sind die möglichen Eskalationsstufen, die wir haben, und was folgt oder resultiert dann eben daraus.
Genau, das ist wichtig. Es hilft nichts, wenn ich reinschreibe, wir haben Eskalationsstufen 1 bis 4, von gering bis sehr hoch, sondern ich muss auch dahinter schreiben, was das bedeutet. Das ist übrigens ein generelles Thema in sämtlichen Dokumenten, dass man eine Eindeutigkeit voraussetzt, die man nicht immer hat, sondern schreibt es einfach auf, dann ist es eindeutig.
Dann finde ich wichtig, haben wir eben auch schon kurz darüber gesprochen, nur kurz noch zum Auffrischen, wir brauchen diese Notfallkontakte, wen rufe ich wann an, wer ist mein IT-Dienstleister des Vertrauens, wer ist vielleicht mein IT-Forensiker des Vertrauens, wo, du hast Versicherung eben gesagt, was ist die Notfallrufnummer der Versicherung, und auch da, wir hatten das eben schon kurz angeschnitten, wenn ich eine Cyberversicherung habe, dann gehört die Telefonnummer von der Cyberversicherung in die gesamte Dokumentation mit rein, und wenn ich eine Cyberversicherung habe, müsste ich, klärt vorher über die Cyberversicherung Thema IT-Forensiker und weitere Maßnahmen, viele Versicherungen haben eigene Forensiker, haben Partnerunternehmen, haben sonst irgendwas und definiert darüber die Reihenfolge, wenn ich zuerst anrufe.
Wenn nämlich in der Police von der Versicherung drinsteht, dass die Versicherung eigene Forensiker stellt, macht es keinen Sinn, wenn ich mir oben irgendeinen anderen aussuche, mir einen anderen auswähle und irgendeinen anderen anrufe, weil dann kriege ich wieder Ärger mit meiner Versicherung.
Das wäre eher kontraproduktiv, wenn man die dann selber zahlen muss.
Forensik ist nicht günstig. Deswegen kennt, deswegen kennt eure Versicherungspolize, klingt jetzt auch blöd, aber gerade im Kontext mit der ITler und die Geschäftsleitung oder die Compliance-Abteilung, stimmt euch da ab. Habt ihr überhaupt eine Versicherung?
Das wäre schon mal gut gewesen. Bei wem habt ihr sie? Welche Ansprechpartner?
Welche Rufnummer und welche Leistung? Beziehungsweise, was erwartet die Versicherung für Steps, dass das klar ist und schreibt das ins Notfallhandbuch ein? Das finde ich noch super wichtig bei Dingen.
Und habt es offline verfügbar? Da haben wir, glaube ich, auch gerade drüber gesprochen, dass wir immer einen zweiten redundanten Ort für das Ding suchen.
Ja, und wenn wir halt zu Anfang über Rollenverantwortlichkeiten dann Eskalationsstufen gesprochen haben und die Notfallkontakte, dann ist sicherlich der Kommunikations-, also ein Kommunikationsleitfaden sinnvoll, auch der gerne gekoppelt an die Eskalationsstufen. Nennen wir mal ein Beispiel von gerade eben. Okay, ich habe jetzt ein Virus lokal auf einem System.
Okay, interne Kommunikation brauche ich wahrscheinlich nicht nach draußen tragen, je nachdem, was es ist natürlich. Sobald wir hocheskalieren, ja, dann sieht die Kommunikation auch ganz anders aus und auch wohin ich kommuniziere. Dementsprechend auch das sollte niedergeschrieben sein, damit halt klar ist, wer mit wem spricht, wohin welche Informationen fließen können, sollen, müssen.
Und ja, gehört halt für mich da auch mit rein. Und als Techniker ganz sicher technische Checklisten. Auf jeden Fall, ja.
Also ja, auch das gehört ja irgendwo mit in diesen Maßnahmenplan oder in den Notfallplan, wo man dann einfach sagt, okay, die Dinge werden jetzt als allererstes abgearbeitet. Die kann ich so check, check, check. Und dann geht es immer tiefer, je nachdem, was man gerade für einen Fall hat.
Genau. Entscheidungsbefugnisse haben wir eben schon drüber gesprochen. Glaube ich, da können wir schnell drüber weggehen.
Einfach nochmal ein Reminder. Wir hatten es uns mit aufgeschrieben, dass wir es nicht vergessen. Entscheidungsbefugnisse sind super wichtig.
Wer darf was entscheiden in diesem Moment? Und was wir als allerletztes haben, ist, was ich super wichtig finde, ist, wir müssen oder wir brauchen eine Wiederanlaufstrategie. Also klassisch, wie holen wir uns aus diesem System wieder raus?
Was hatten wir für Learnings aus den letzten Vorfällen? Sind die ähnlich, sind die vergleichbar? Was haben wir da gemacht?
Wie kriege ich Systeme wieder hochgezogen? Und bei der Wiederanlaufstrategie ist auch super wichtig, die Reihenfolge. Dass einfach von vornherein klar ist, in welcher Reihenfolge fahre ich Systeme wieder hoch und welche Systeme haben Priorität.
Und bei der Priorität ist im Wiederanlaufplan auch immer nochmal so gesagt, wenn ich so Sachen habe, ich gehe so in eine Krise rein, also ich habe Vorfall, dann muss ich eine Zeit lang mein Unternehmen in diesem Vorfallstadium mit Analyse, mit Erkennung etc. Ist das so eine Zeit lang im Krisenmodus und ich hole es dann aus dem Krisenmodus wieder hoch in den Normalbetrieb rein durch den Wiederanlaufplan. Und für diesen Krisenbetrieb muss klar sein, was sind die Core-Prozesse?
Was lasse ich zuerst wieder laufen? Was lasse ich in einem Notbetrieb an irgendeiner Stelle zu? Wie würde ein Notbetrieb aussehen?
Was sind gegebenenfalls für genau diese Systeme Redundanzen, die ich vorgesehen habe, Alternativen, auf die ich rübergehen kann? Also diese Sachen ist in der Wiederanlaufstrategie und in der Notfall-Krisenstrategie auf jeden Fall mit zu beschreiben. Und da ist ganz klassisch, sind wir immer wieder, wir hatten das glaube ich auch in einer der letzten Folgen, ich muss meine IT-Systeme kennen.
Und nur wenn ich meine IT-Systeme kenne, weiß ich, wie kritisch meine IT-Systeme ist. Das ist klassisches Informationssicherheitsthema ACID. Und wenn ich weiß, was kritisch ist, dann kann ich mir auf diese kritischen Systeme in meinem Notfallhandbuch, kann ich mir Gedanken machen, mit welcher Wiederanlaufstrategie und wie mit welcher Priorisierung ich an die Systeme drangehe.
Und das ist ein super wichtiges Thema für das Notfallhandbuch.
Genau. Eine Sache würde ich gerne nochmal einwerfen wollen. Wir haben ja über vorhin Entscheidungen, also du hattest das eigentlich gesagt, wenn jetzt jemand entscheidet, okay, wir holen jetzt einen IT-Forensiker dazu oder sonst irgendwas.
Und du hast zu Anfang gesagt, dass es nicht richtig ist, das hört sich jetzt irgendwie falsch an, aber es ist nicht richtig, den ITler mit dieser Aufgabe allein zu lassen. Wenn wir jetzt mal das Beispiel nehmen, meine Systeme werden verschlüsselt und es wird auf meinem Bildschirm angezeigt, wir sollen Lösegeld zahlen. Das kann der ITler nicht entscheiden.
Auf keinen Fall. Der kann zwar eine Empfehlung geben und ungefähr sagen, vielleicht kann er das, es ist auch immer schwierig, kommt darauf an, an welcher Stelle man steht, aber er kann vielleicht eine Einschätzung geben, ob es jetzt einfacher ist oder nicht. Aber wir haben auch schon mehrfach darüber gesprochen, traut man jemanden, der einem wirklich schon einmal übers Ohr gehauen hat, der einen überhaupt erst in die Situation gebracht hat.
Aber wenn wir jetzt einfach nur darüber sprechen, zahlen wir Lösegeld oder nicht, dann trifft diese Entscheidung nicht die IT, dann trifft die Entscheidung das Management. Wer auch immer das dann sein mag, Geschäftsführung direkt oder auf Basis von.
Ganz genau. Je nachdem, wie du da drin bist, hast du Behörden mit dabei, hast Forensiker mit dabei, wenn du versichert bist, das Versicherungsunternehmen mit dabei und dann wird das gemeinschaftlich vom Management entschieden mit den externen Parteien, die ich gerade genannt habe, und dann treffen die Entscheidungen, was gemacht wird und was nicht getan wird. Kommt auch darauf an, ob es von der Versicherungssumme gedeckelt ist, ob die Polizei sagt.
Ja, also auf gar keinen Fall, auf gar keinen Fall mischt sich da in irgendeiner Art und Weise die IT ein.
Vor allem der traurige, der traurige, die arme Sau, so möchte ich es mal sagen, sitzt da vor diesem Rechner und soll noch so eine Entscheidung treffen.
Soll dann auch noch sagen, ja Chef, gib mal drei Bitcoins her.
Nein.
Ja, nein, das macht nicht, macht nicht der ITler. Der darf gerne gefragt werden, aber der entscheidet auf gar keinen Fall.
So und damit kriegen wir jetzt den Bogen halt wirklich dahin. Der ITler soll eben keine, so eine Entscheidung treffen, aber was muss wirklich untersucht werden, wenn wir es jetzt mal rein technisch sehen. Ich glaube, ist klar, Einfallstor, das ist so das Erste.
Woher kommt das Ganze, über welchen Weg, sowas, das ist halt wirklich das Erste, was geprüft werden muss. Dann gehen wir rüber zur, ja, Eskalation. Also eskalieren ist in die eine oder andere Richtung, was natürlich dazugehört.
Und was sind die, was kann aus diesem Befall, der da gerade vorliegt, resultieren, ist auch ein Teil der Eskalation. Dann, wie breitet sich das Ganze in meinem Netzwerk aus? Also es gibt ja, wie ich gerade gesagt habe, entweder diese lokalen Sachen, ist aber mittlerweile schon viel, viel seltener geworden, oder breitet es sich über Netzlaufwerke aus, breitet es sich, keine Ahnung.
Egal wie, auch das muss klar untersucht werden, wie es sich ausbreitet. Dann besteht die Gefahr, dass Daten abfließen. Also je nachdem, was es ist, aber könnte es sein, dass meine Daten gerade ins Internet hochgeladen werden, ich selber keinen Zugriff mehr drauf habe, dass ich also auch an der Stelle ein Problem bekomme, weil meine Daten im Internet verkauft werden können, Geschäftsgeheimnisse und so weiter.
Oder ich sag mal, wenn man selber etwas ausgearbeitet hat, Innovationen entwickelt hat, ist das natürlich hochschädlich. Und dann ganz klar, was sind die Aktionen daraus? Was machen wir jetzt, um unsere Möglichkeiten einzudämmen?
Das sind genau die Punkte, die technisch durchleuchtet werden müssen. Und da ist der IT-Lehrer wieder der Richtige.
Da darf man wieder gefragt werden, vor allem Sie damit dazu, ja. Aber das zeigt doch alles, dass Inzidenz eben kein Virusproblem ist. Das ist das, womit wir eingeleitet haben, angefangen haben.
Das ist halt, um zum Ende zu kommen, das ist halt einfach kein Virusproblem.
Ich habe es jetzt ein paar Mal als Beispiel genannt, aber nein, das hat nichts rein mit so einem Virus oder so, wie man ihn aus der klassischen Zeit kennt. Damit hat es halt wirklich nichts zu tun. So Michael, dann kommen wir mal wieder in deinen Redefluss.
Was passiert denn nach dem Angriff? Ich meine technisch, okay, kann alles gelöst sein, aber was ist danach aus deiner Sicht? Was muss getan werden?
Na ja, also du solltest ja in dieser Phase schon, wir haben ja eben über diese verschiedenen Phasen gesprochen, du solltest dann, wenn du hoffentlich aus dieser ganzen Sache wieder draußen bist, eine vernünftige Ursache kennen und wissen, wo dein Problem herkommt. Auf Basis von diesen Themen solltest du natürlich, gehen wir mal kurz ins Normative sein, Vorfallsmanagement ist eine Korrekturmaßnahme. Danach solltest du allerdings eine Vorbeugemaßnahme, um zu gucken, dass das nicht wieder passiert und um Maßnahmen abzuleiten, um es nachhaltig zu verhindern.
Das heißt, du solltest ganz klassisch mit der Ursachenanalyse anfangen. Was kann ich daraus besser machen und solltest deine Systeme entsprechend anpassen? Learnings, ganz klassisch, Learnings mitnehmen.
Und zu den Learnings gehört halt, das kann sowohl technisch als auch organisatorisch sein. Das heißt, wir kaufen noch irgendwas, um das Problem zu lösen. Wir segmentieren noch weitere Netzwerke, wir holen uns noch eine Firewall, Firewall ist auch ein Thema, wir holen uns noch eine Firewall, wir machen jetzt dies noch obendrauf, wir kaufen uns noch eine Software, wir holen uns jetzt irgendein Siebenmanagement, um irgendwie permanent eine Überwachung drauf zu haben, was auch immer.
Kann aber auch organisatorisch sein mit, ich mache eine neue Erwärmungsschulung, ich hole meine Mitarbeiter nochmal ins Boot. Das kann organisatorisch auch sein, ich erhöhe die Versicherungssumme oder das kann auch organisatorisch sein, ich hole mir überhaupt mal eine Versicherung für das ganze Thema. Also das sind so die Maßnahmen und die Learnings, die ich daraus erarbeiten sollte.
Parallel habe ich natürlich dieses Klassische, wenn ich eine Versicherung habe, das wird halt einen gewissen Rattenschwanz dauern, bis die Versicherungsabwägung wirklich abgeschlossen ist, bis das richtig durch ist, bis die Beiträge neu berechnet worden sind und gegebenenfalls, wenn es juristisch ist, kann das da halt auch noch so ein Nachspiel haben und kann dich da halt auch noch einen Moment daraus verfolgen. Also auch da, ja.
Also zusammengefasst, kann man es halt wirklich nochmal, du hast es gesagt, Lessons learned. Also was haben wir wirklich aus den ganzen Sachen gelernt?
Ja.
Ja, Michael. Ich würde sagen, zusammengefasst, das Ganze nochmal einmal kurz runtergebrochen, Incident Response beginnt halt nicht erst im Ernstfall. Das hatten wir ein paar Mal jetzt angeschnitten, also wenn du jetzt Partner für Forensik oder sowas suchst, mach das, wenn kein Problem vorliegt.
Genau. Dann hast du gute Partner an der Hand, falls es dann soweit ist. Und logischerweise Maßnahmenplan, Notfallplan, Vorfallsmanagement, all diese Sachen, die müssen halt permanent laufen, aktuell gehalten werden.
Und auch gerne mal geübt werden. Auch das. Aber wir sind beim Awareness Training, klassische Auditorenfragen, ganz klassische Sache, wie oft, also Klassiker ist, ich prüfe, dass mein Backup wieder herstellbar ist.
Das ist ja auch schon ein Teil dieser Strategie. Aber auch diese Meldewege, das Aktivieren von so einem Krisenstab, wer trifft sich zusammen, wie kommunizieren die den ganzen Kram. Ich überlege mir das schon theoretisch und ich arbeite mir da was raus, aber ich kann es halt auch gerne mal durchspielen.
Das ist so eine Sache, das muss man vielleicht einfach mal machen. Das heißt jetzt nicht, dass der ITler in den Serverraum gehen soll und soll einfach mal den Server am Hauptschalter abschalten und gucken, wie die Firma darauf reagiert. Aber es gibt durchaus Möglichkeiten, um gewisse Situationen zu simulieren, um zu gucken, ob ein Meldeweg überhaupt losgeht, wie er losgeht und wie mein Unternehmen funktioniert in genau diesen Momenten.
Und das sollte man, muss man üben. Mit der Feuerwehr übt man im Unternehmen regelmäßig, wie man einen Feuerlöscher bedient, wo der Brandplatz ist, dass der Keil in der Tür aus Holz sein sollte. Also all diese Spielereien macht man regelmäßig auch in Wiederauffrischungsdinger.
Man macht Arbeitssicherheit regelmäßig und das gehört dazu. Sowas muss man auch, einen IT-Vorfall muss man auch mal durchspielen, sprich üben. Richtig.
Und abschließend, wir haben ja in letzter Zeit immer so, eine Phrase würde ich jetzt nicht nennen, wir haben aber die letzte Zeit oft mit Phrasen abgeschlossen. Tue ich heute vielleicht angeschnitten auch. Das ganze Thema beginnt eigentlich immer mit der ehrlichen Frage, sind wir vorbereitet oder hoffen wir es eigentlich nur?
Sind wir vorbereitet oder sind wir so klein, das passiert uns nie?
Ja, das ist die richtige Frage, genau. Ich kann dich nicht hören, also du kannst reden, wie du willst. Gut.
Alles halb so wild. Zum Glück ist es erst ganz zum Schluss ausgefallen. Dementsprechend, wir haben, glaube ich, ganz viele wichtige Infos von Michael auch bekommen.
Er kann sich jetzt leider eben nicht verabschieden. Er schreibt mir gerade parallel, Notfall, das Mikro ist ausgefallen. Da muss man jetzt halt gucken, wie hoch man das eskalieren würde, im Ernstfall.
Vielen Dank, Michael. Vielen Dank in die Runde. Wenn ihr irgendwas in diese Richtung habt, wenn ihr Fragen habt, wenn ihr auch euch Themen wünscht, meldet euch immer gerne.
Ihr könnt uns anschreiben, ob es dann eben per Mail ist, egal. Also auf allen Kanälen könnt ihr euch gerne melden. Schaut euch unsere Videos an, folgt uns auf allen Kanälen und ich würde sagen, wir hören uns in 14 Tagen wieder.
Bis dahin wünsche ich euch allen alles Gute. Bis dann. Ciao.
Michael
00:01:00
René
00:01:02
Michael
00:01:03
René
00:01:07
Michael
00:01:23
René
00:01:50
Michael
00:01:53
René
00:02:00
Michael
00:02:04
René
00:02:26
Michael
00:02:35
René
00:02:58
Michael
00:03:49
René
00:04:03
Michael
00:04:43
René
00:05:10
Michael
00:06:21
René
00:07:16
Michael
00:08:38
René
00:09:43
Michael
00:10:19
René
00:11:31
Michael
00:11:38
René
00:13:01
Michael
00:13:16
René
00:14:46
Michael
00:14:58
René
00:15:38
Michael
00:15:46
René
00:17:06
Michael
00:17:52
René
00:17:54
Michael
00:18:15
René
00:18:59
Michael
00:20:32
René
00:22:02
Michael
00:22:28
René
00:22:34
Michael
00:23:14
René
00:24:35
Michael
00:25:54
René
00:26:54
Michael
00:26:55
René
00:28:29
Michael
00:28:57
René
00:28:59
Michael
00:29:00
René
00:29:08
Michael
00:29:09
René
00:29:36
Michael
00:29:42
René
00:29:44
Michael
00:30:04
René
00:30:07
Michael
00:30:44
René
00:30:55
Michael
00:30:58
René
00:31:38
Michael
00:31:40
René
00:31:52
Michael
00:31:57
René
00:31:58
Michael
00:32:01
René
00:32:32
Michael
00:32:35
René
00:32:35
Michael
00:32:38
René
00:32:48
Michael
00:32:53
René
00:33:37
Michael
00:33:43
René
00:33:47
Michael
00:34:09
René
00:35:56
Michael
00:36:24
René
00:36:26
Michael
00:37:15
René
00:39:23
Michael
00:39:59
René
00:40:54
Michael
00:42:39
René
00:43:27
Michael
00:45:38
René
00:47:39
Michael
00:48:37
René
00:50:04
Michael
00:50:07
René
00:50:46
Michael
00:51:58
René
00:54:09
Michael
00:55:35
René
00:56:07
Michael
00:56:14
René
00:56:18
Michael
00:56:19
René
00:56:27
Michael
00:58:18
René
00:58:33
Michael
00:58:59
René
01:00:54
Michael
01:01:01
René
01:01:04
Michael
01:01:38
René
01:03:03
Michael
01:03:26
René
01:03:31
Feedback geben
Dir gefällt der Podcast und Du möchtest das mal loswerden? Du hast Tipps für neue Themen oder magst über den Inhalt bestimmter Folgen diskutieren? Dann wähle im Formular die jeweilige Episode aus und schreib uns eine Nachricht. Vielen Dank für Dein Feedback!