Das Sicherheitssystem schlägt Alarm, höchste Stufe, ein echter Angriff auf ein Benutzerkonto. Die Technik macht alles richtig. Und dann passiert stundenlang nichts, weil niemand hinschaut. Ich erzähle in diesem Erfahrungsbericht, wie ich den Alarm durch Zufall gefunden habe und warum die unbequemste Erkenntnis dieses Tages nicht die Technik betraf, sondern eine Frage, die niemand beantworten konnte.
Ein gewöhnlicher Montag
Es war ein Montag im Spätsommer. Ich betreue als externer Informationssicherheitsbeauftragter einen gemeinnützigen Träger mit mehreren Einrichtungen und einigen hundert Mitarbeitern. Die IT liegt bei einem Dienstleister, der seit Jahren den Betrieb verantwortet, die Arbeitsplätze betreut und die Microsoft-365-Umgebung eingerichtet hat. Ein Haus, wie es viele gibt. Engagierte Menschen, knappe Mittel und eine IT, die im Alltag funktioniert.
Zu diesem Zeitpunkt arbeitete ich an einem Sicherheitsbericht für den Vorstand. Darin stand, was jeder Sicherheitsbeauftragte in solchen Häusern kennt. Die Mehrfaktoranmeldung war nicht für alle erzwungen. Veraltete Anmeldeverfahren waren noch offen. Und die Frage, wer im Haus eigentlich die Kontrolle über die Umgebung hat, war nicht sauber beantwortet. Der Bericht war fundiert, die Empfehlungen waren klar. Und ich wusste aus Erfahrung, wie solche Berichte oft enden. Sie werden gelesen, gelobt und vertagt.
Der Blick, der nicht geplant war
An diesem Nachmittag öffnete ich das Sicherheitsportal des Tenants, eigentlich nur, um für den Bericht eine Einstellung nachzusehen. Oben in der Liste stand ein Vorfall mit dem höchsten Schweregrad. Ein Benutzerkonto war Ziel eines Angriffs vom Typ Adversary in the Middle geworden. Bei dieser Methode schaltet sich der Angreifer beim Anmelden unbemerkt zwischen den Nutzer und Microsoft. Er greift dabei nicht nur Benutzername und Kennwort ab, sondern die bereits angemeldete Sitzung. Damit lässt sich selbst eine Mehrfaktoranmeldung umgehen. Microsoft ordnete die Infrastruktur einem finanziell motivierten Angreifer zu, der typischerweise Postfächer für Rechnungsbetrug missbraucht.
Die Meldung war nicht neu. Sie lag seit Stunden dort. Das System hatte den Angriff sofort und korrekt erkannt. Es hatte alles getan, was ein Sicherheitssystem tun kann. Nur hatte niemand die Meldung gelesen.
Ich erinnere mich an den Moment ziemlich genau. Es war kein Schreck, eher eine Art kalte Klarheit. Hätte ich an diesem Tag nicht zufällig nach dieser einen Einstellung gesucht, wäre der Alarm vermutlich bis zum nächsten Morgen liegen geblieben. Vielleicht länger.
Erst handeln, dann fragen
Die ersten Stunden gehörten dem Handwerk. Das betroffene Konto wurde gesichert, das Kennwort zurückgesetzt, alle aktiven Sitzungen beendet und die Mehrfaktoranmeldung für dieses Konto neu eingerichtet. Der Dienstleister prüfte Postfach und Anmeldevorgänge auf Spuren eines Zugriffs, untersuchte das betroffene Gerät und sperrte die Adresse des Angreifers. Ich ließ mir alle Maßnahmen und Prüfergebnisse schriftlich bestätigen. Parallel lief die datenschutzrechtliche Prüfung, denn ein Zugriff auf ein Postfach mit personenbezogenen Daten ließ sich zunächst nicht ausschließen. Die Frist von 72 Stunden nach Artikel 33 DSGVO lief ab dem Moment der Kenntnis. Ein Meldungsentwurf lag vorsorglich bereit, bevor die Prüfergebnisse kamen.
Das alles funktionierte gut, und das sage ich ausdrücklich. Der Dienstleister reagierte schnell und kompetent, als er einmal Bescheid wusste. Genau darin lag aber das Problem.
Die Frage, die niemand beantworten konnte
Als die Lage unter Kontrolle war, stellte ich dem Dienstleister drei Fragen: Wer überwacht bei Ihnen die Sicherheitsmeldungen dieses Tenants? Wer ist bei einem Sicherheitsvorfall intern zuständig? Und wie verläuft der Meldeweg zu uns?
Auf keine der drei Fragen gab es eine klare Antwort. Nicht aus Nachlässigkeit, sondern weil sie nie gestellt worden waren. Der Dienstleister betrieb die Umgebung, und er betrieb sie ordentlich. Ob die Überwachung der Sicherheitsmeldungen zu seinem Auftrag gehörte, konnte niemand sagen. Im Vertrag stand es jedenfalls nicht erkennbar. Beide Seiten waren stillschweigend davon ausgegangen, dass sich der jeweils andere darum kümmert.
Das war der Wendepunkt, und er war unangenehm. Denn plötzlich ging es nicht mehr um einen Angreifer, sondern um eine Lücke, die wir alle gemeinsam übersehen hatten. Das Haus, der Dienstleister und auch ich. Ich hatte in meinem Bericht über Mehrfaktoranmeldung und Notfalladministratoren geschrieben. Die Frage, wer eigentlich auf einen Alarm reagiert, stand nicht darin.
Der Preis der Ehrlichkeit
Es gibt in solchen Momenten eine bequeme Version der Geschichte. Der aufmerksame Sicherheitsbeauftragte entdeckt den Angriff, der Dienstleister hat geschlafen, der Vorstand muss handeln. Diese Version hätte ich schreiben können. Sie wäre nicht einmal falsch gewesen. Aber sie hätte das eigentliche Problem verdeckt.
Ich habe mich für eine andere Fassung entschieden. In der Anlage zum Sicherheitsbericht, die ich noch am selben Tag für den Vorstand schrieb, steht ein Satz, der mir wichtig war. Die Technik hat funktioniert, die Organisation nicht. Und direkt darunter steht, dass der Angriff nur durch einen zufälligen Blick entdeckt wurde und nicht durch einen geregelten Prozess. Das ist auch eine Aussage über meine eigene Rolle. Zufall ist kein Prozess, auch dann nicht, wenn er beim Sicherheitsbeauftragten stattfindet.
Diese Offenheit hat einen Preis. Das Gespräch mit dem Dienstleister war nicht einfach, denn niemand hört gern, dass eine zentrale Aufgabe in keinem Vertrag steht. Und dem Vorstand einen realen Angriff zu schildern, der nur durch Glück begrenzt blieb, ist etwas anderes, als einen Bericht mit Empfehlungen vorzulegen. Aber genau dieser Unterschied war der Punkt.
Was sich verändert hat
Der Vorfall hat den Sicherheitsbericht nicht verändert. Er hat ihn beglaubigt. Was vorher ein Risiko auf Papier war, hatte jetzt ein Datum, ein betroffenes Konto und einen höchsten Schweregrad. Die Empfehlungen waren dieselben wie vorher. Die Mehrfaktoranmeldung für alle und am VPN, die Blockade veralteter Anmeldeverfahren und eigene Notfalladministratoren im Haus, damit der Träger die Kontrolle über seine Umgebung behält. Neu war, dass sie niemand mehr für theoretisch halten konnte.
Dazu kam eine Empfehlung, die im ursprünglichen Bericht fehlte. Der Träger braucht einen festen Meldeweg und ein einfaches Vorfallmanagement. Und es muss verbindlich geklärt sein, wer die Sicherheitsmeldungen überwacht und innerhalb welcher Zeit darauf reagiert wird. Diese Zuständigkeit gehört in den Vertrag mit dem Dienstleister, mit Namen, Erreichbarkeit und Reaktionszeit. Solange sie nirgends steht, gehört sie niemandem.
Beim Schreiben dieser Zeilen liegen die Entscheidungen beim Vorstand. Ich weiß nicht, ob alle Empfehlungen in der vorgeschlagenen Reihenfolge umgesetzt werden. Das ist der Teil dieser Geschichte, der noch nicht fertig ist. Aber die Diskussion hat sich verschoben. Früher ging es darum, ob Sicherheitsmaßnahmen nötig sind. Jetzt geht es darum, wie schnell.
Was ich daraus mitnehme
Ich habe über 30 Jahre in der Informationssicherheit gearbeitet, und dieser Nachmittag hat mir trotzdem etwas beigebracht: Wir prüfen bei Dienstleistern, was sie tun. Wir prüfen aber selten, was zwischen den Verträgen liegt. Die gefährlichste Lücke in diesem Fall war keine technische Schwachstelle, sondern eine Aufgabe, von der jede Seite annahm, dass die andere sie erledigt.
Wenn Sie als Sicherheitsbeauftragte eine Umgebung betreuen, die ein Dienstleister betreibt, dann stellen Sie die drei Fragen, bevor der Alarm kommt: Wer schaut hin, wer entscheidet, und wie erfahren Sie davon? Wenn die Antworten klar sind, ist das Gespräch in fünf Minuten erledigt. Wenn nicht, haben Sie gerade die wichtigste Lücke in Ihrer Dienstleistersteuerung gefunden.
Erkennung ohne Reaktion schützt nicht. Diesen Satz habe ich an diesem Tag in einen Bericht geschrieben. Ich hätte ihn gern früher geschrieben.
Weiterlesen
Wie Sie die Zugänge und Zuständigkeiten Ihrer Dienstleister technisch in den Griff bekommen, zeigt der Beitrag „So behalten Sie die Fernwartungszugänge Ihrer Dienstleister im Griff“ aus dieser Ausgabe.
Warum die Dienstleisterliste allein kein Risikomanagement ist, begründet dieser Kommentar.
Wie Sie im Ernstfall die richtige Reihenfolge einhalten, beschreibt die Ausgabe 17.
Die Mehrfaktoranmeldung und den bedingten Zugriff in Microsoft 365 behandelt Ausgabe 19.
