«02:14» Die Nacht, in der nichts passiert ist

Diese Geschichte beginnt mit einem Server und mit einer Entscheidung, die viele IT-Team schon so getroffen haben. Montag, 16:44 Uhr: Irgendwo im Netz läuft ein automatisierter Scanner über die von aussen erreichbaren Systemen einer Regionalbank und findet, wonach er sucht. Ein VPN-Gateway, dessen Software eine Version zu alt ist. Für die Lücke gibt es seit Wochen einen Patch, ein Ticket und ein geplantes Wartungsfenster. Es wurde zweimal verschoben, bewusst und begründet: Ein Projekt hatte Vorrang und niemand wollte ein zentrales System ausgerechnet während des laufenden Betriebs anfassen. Das war kein Versäumnis, sondern eine ganz normale Abwägung in einem Betrieb, in dem hundert Dinge gleichzeitig Priorität haben. Genau solche Abwägungen trifft jedes IT-Team täglich, und genau deshalb braucht es eine zweite Verteidigungslinie für den Fall, dass eine davon einmal danebenliegt.

Der Angreifer nutzt die Lücke aus und hat einen Fuss im System. Bis hierhin unterscheidet sich nichts, gar nichts, von einem gewöhnlichen Angriff über eine bekannte, ungepatchte Schwachstelle. Derselbe Angreifertyp, dieselbe Methode, dieselbe Qualität. Der Unterschied beginnt damit, dass diese Bank vor zwei Jahren eine Entscheidung getroffen hat. Nicht aus Weitsicht, wie der IT-Leiter heute freimütig zugibt, sondern aus Druck: Die Regulierung (FINMA) verlangte Nachweise, der Verwaltungsrat stellte Fragen, eine Risikoanalyse brachte es an den Tag: niemand schaute nachts auf die Systeme, und niemand wusste, wen man im Ernstfall anruft. Seither laufen die Signale der Bank in ein Security Operations Center, es gibt einen Incident-Response-Retainer mit vertraglich zugesicherten Reaktionszeiten, und einmal im Jahr spielt die Geschäftsleitung in einer Übung den Ernstfall durch. Bei der ersten Übung, erinnert sich der IT-Leiter, wusste niemand, wer den Krisenstab leitet. Es war ein unangenehmer Nachmittag. Es war der wertvollste Nachmittag seit Jahren.

Montag, 21:03 Uhr: Vom kompromittierten Gateway aus tastet sich jemand weiter ins interne Netz vor. Die Bewegung ist unauffällig genug, um keine Alarm auszulösen, denn Systeme kommunizieren miteinander, das ist ihr Zweck. Das SOC überwacht sie trotzdem. Der Angreifer verhält sich ruhig, sieht sich um, wartet. Um 02:13 Uhr macht er den Schritt, den jeder Angreifer irgendwann machen muss: Er versucht, von diesem Server aus auf einen internen Dateidienst zuzugreifen, auf dem die Kreditdossiers liegen. Und in diesem Moment fügt die Korrelation im SOC mehrere Alarme zusammen, die einzeln harmlos wirken: dass ein von aussen erreichbarer Server plötzlich eine Kommandozeile startet, dass von genau diesem Server eine Verbindung ins Ausland aufgebaut wird, und dass er auf ein internes System zugreifen will, das er in seinem ganzen Betriebsleben noch nie berührt hat.

02:14 Uhr: Ein Incident erscheint auf dem Bildschirm des diensthabenden Analysten. 02:15 Uhr: Die Automatisierung hat den betroffenen Server bereits vom Netz isoliert und die aktiven Sitzungen gekappt; der Angreifer verliert seinen Zugang, bevor ein Mensch eingegriffen hat. Was dann folgt, ist keine Heldentat, sondern Routine, und genau das ist der Punkt: Der Analyst erkennt, dass der Angreifer bereits versucht hat, auf die internen Systeme zuzugreifen. Da Umfang und Dauer des Angriffs zu diesem Zeitpunkt noch unbekannt sind, eskaliert er den Incident.

Um 02:31 Uhr klingelt beim IT-Leiter das Telefon, nicht als Panikanruf, sondern als Schritt drei eines Playbooks, dass beide Seiten kennen. Er stellt zwei Fragen, die im Playbook stehen, bestätigt die Isolation und ruft die Hotline seines Incident-Response-Retainers an, mit vertraglich zugesicherter Reaktionszeit. Innerhalb von Minuten ist ein Incident Responder am Telefon. Im Scoping-Call wird der bisherige Incident besprochen, die Vorgehensweise definiert und sich über die bisherigen Erkentnisse und Aktivitäten ausgetauscht. Der IT-Leiter ist froh einem vorbereiteten Incident Response Plan zu folgen und trotz fortgeschrittener Uhrzeit handlungsfähig zu sein. Um 03:45 Uhr beginnt das CSIRT mit der eigentlichen forensischen Arbeit. Das CSIRT arbeitet zusammen mit dem SOC um die Gateway-Logs effizient zu sichten und so den initiale Angriffsvektor über den Exploit zu identifizieren. Zusammen mit den Netzwerk-Logs lässt sich feststellen, dass sich der Angreifer noch nicht erfolgreich im Netzwerk fortbewegen konnte. In regelmässigen Abständen steht das CSIRT mit dem IT-Leiter und dem SOC im Austausch und berichtet über neue Erkenntnisse, eventuell benötigte Logs oder Aktionen, die durchgeführt werden. Die gesamte Umgebung wird durchsucht: keine weiteren kompromittierten Systeme, keine zweite Spur, keine hinterlassene Hintertür. Der Angriff wurde früh gestoppt, bevor sich der Angreifer lateral im Netzwerk bewegen konnte.

Nach einer intensiven Nachtschicht ist der Vorfall um 08:30 Uhr so weit aufgeklärt, dass alle Beteiligten den verpassten Schlaf nachholen, bevor am nächsten Tag die Nachbearbeitung beginnt. Der IT-Leiter wird später sagen, das sei der Moment gewesen, in dem sich zwei Jahre Vorbereitung zum ersten Mal wirklich ausbezahlt hätten: nicht die Technik, die Ruhe. Die Verantwortlichkeiten waren klar, jeder konnte strukturiert arbeiten, und man wusste genau, wer um drei Uhr nachts abnimmt.

Einige Tage später liegt bei der Geschäftsleitung ein einseitiger Bericht: was geschah, was automatisch passierte, was das CSIRT verifiziert hat, was noch zu tun ist. Das Gateway wird aus dem Betrieb genommen, sauber neu aufgesetzt und endlich gepatcht, die Lücke geschlossen. Es wird ein neuer Patchprozess definiert, um kritische Systeme zeitnah zu aktualisieren, und die dafür benötigten Ressourcen werden genehmigt. Niemand wird für das verschobene Wartungsfenster verantwortlich gemacht, denn die Entscheidung war zu ihrem Zeitpunkt richtig, und das wird intern auch so kommuniziert. Denn wer für einen aufgeschobenen Patch an den Pranger gestellt wird, meldet den nächsten offenen Punkt lieber gar nicht. Nicht die Priorisierung war das Problem, sondern die Annahme, dass Prävention allein reicht. Die Erkenntnis, die bleibt, ist eine andere: Die Prävention hatte diese eine Lücke übersehen. Die Überwachung hat sie aufgefangen, die vorbereitete Reaktion hat sie beendet. Genau dafür gibt es beide. Gemäss dem vorbereiteten Prozess geht eine Meldung an die zuständigen Stellen, nicht aus Angst, sondern weil der Ablauf dafür längst definiert ist. Und zwei Wochen später passiert das, was aus einem abgewehrten Angriff einen Gewinn für viele macht: Die Erkenntnisse aus dem Fall fliessen als verfeinertes Tuning ins SOC und als geschärfte Playbooks in den Retainer ein. Der nächste Angriff wird nicht nur früher erkannt, sondern auch schneller beantwortet.

Das Bemerkenswerteste an dieser Geschichte ist, was in ihr fehlt. Kein tagelanger Krisenstab, keine bange Frage nach dem Lösegeld, keine fünf Tage Stillstand. Für das SOC und das CSIRT ist ein solcher Fall Alltag; solche Angriffe werden regelmässig genau so gestoppt. Die Geschäftsleitung erfuhr am Dienstagmorgen, dass ein System, das seit Wochen auf ein Update wartete, beinahe der Anfang von etwas Grossem gewesen wäre. Beinahe. Es war das oft befürchtete Szenario, das bisher immer nur die anderen getroffen hatte, nun war sie selbst betroffen, aber ohne Schaden und ohne grösseren Business-Impact. In der Bank erzählt man sich die Nacht vom Montag heute als die Geschichte, in der nichts passiert ist, und der IT-Leiter korrigiert dann jedes Mal: Es ist die Geschichte, in der alles passiert ist. Nur haben wir uns zwei Jahre früher darauf vorbereitet und so reagieren können.