Eine überwachte Angriffserkennung hat eine Eigenschaft, die sie von fast jedem anderen IT-Dienst unterscheidet: Sie darf in Ihre Systeme eingreifen, nachts, ohne Sie zu fragen. Das ist ihr Zweck – ein Angreifer, der um 2:40 Uhr Rechte sammelt, muss um 2:43 Uhr gestoppt werden, nicht um 7:30 Uhr. Es ist aber auch ihr Risiko. Ein Analyst, der ein System isoliert, das nachts Aufträge aus Asien entgegennimmt, hat nach Lage der Alarme richtig gehandelt und dem Betrieb trotzdem geschadet.
Ob das geschieht, entscheidet sich nicht in der Nacht. Es entscheidet sich beim Onboarding, in einer Liste, die festlegt, was mit welchem System geschehen darf. Diese Liste ist die wichtigste Stunde des ganzen Vertrags, und sie wird in vielen Einführungen in zehn Minuten abgehakt. Dieser Beitrag beschreibt, wie sie entstehen sollte.
Drei Klassen für jedes System
Der Kern der Liste ist eine Einteilung aller überwachten Systeme in drei Klassen. Sie ist bewusst grob; feiner wird sie in der Praxis nicht gebraucht, und feiner wird sie nicht gepflegt.
- Frei: Das System darf ohne Rückfrage isoliert werden, Prozesse dürfen beendet, Konten gesperrt werden. Typisch: Arbeitsplätze, Dateiserver, Mailserver, Domänencontroller – alles, dessen vorübergehender Ausfall ärgerlich, aber nicht betriebskritisch ist, und alles, dessen Übernahme durch einen Angreifer katastrophal wäre.
- Nur nach Anruf: Der Analyst meldet, empfiehlt und wartet auf eine Entscheidung aus der Rufkette. Typisch: Warenwirtschaft mit nächtlichen Schnittstellen, Produktionssteuerung, Kassensysteme, Systeme mit laufenden Verträgen zu Dritten. Hier ist der Schaden durch eine falsche Isolation so groß wie der durch einen Angriff.
- Nie: Das System wird überwacht, aber nicht angefasst – oder gar nicht eingesehen. Typisch: Medizintechnik mit Herstellerfreigabe, Steuerungen, die auf Netzunterbrechung mit Notabschaltung reagieren, Systeme unter Fremdverantwortung. Für diese Klasse gilt: Die Erkennung meldet, der Mensch handelt, und zwar der, der das System kennt.
Die Versuchung ist, aus Vorsicht zu viel in die zweite und dritte Klasse zu legen. Das macht die Erkennung wirkungslos: Ein Analyst, der bei jedem Vorfall anrufen muss, erreicht um drei Uhr niemanden und handelt nicht. Die Frage für jedes System lautet deshalb nicht „Könnte eine Isolation schaden?“, sondern „Ist der Schaden einer falschen Isolation größer als der Schaden einer verpassten Übernahme?“. Für den Dateiserver lautet die Antwort fast immer nein. Für die Produktionssteuerung fast immer ja.
Die Ausnahmen: was regelmäßig nach Angriff aussieht
Der zweite Teil der Liste sind die Vorgänge, die wie ein Angriff aussehen und keiner sind. Sie sind der Grund für die meisten Fehlalarme in den ersten Wochen – und für die meisten unnötigen Anrufe. Die üblichen Verdächtigen:
- Die nächtliche Sicherung: Ein Dienstkonto greift auf alle Dateien zu, liest sie massenhaft und schreibt sie woandershin. Ohne Ausnahme ist das ein Alarm der höchsten Stufe.
- Die Softwareverteilung: Ein Prozess installiert auf hundert Geräten gleichzeitig etwas, mit Systemrechten, oft nachts.
- Wartungswerkzeuge: Fernwartung, Skriptumgebungen, Werkzeuge zur Verwaltung von Verzeichnisdiensten – genau die, die auch Angreifer nutzen.
- Monatsabschluss und Stapelläufe: Datenbankprozesse, die einmal im Monat Dinge tun, die sie sonst nie tun.
- Fremdzugänge mit Zeitfenster: Der Steuerberater, der Softwarehersteller, der Dienstleister – jeder mit eigenem Konto und eigenem Rhythmus.
Jede Ausnahme wird so eng gefasst wie möglich: dieses Konto, dieser Prozess, dieses Zeitfenster, diese Zielsysteme. Eine Ausnahme „Sicherungskonto darf alles“ ist eine Einladung – das Sicherungskonto ist das erste, das ein Angreifer sucht. Eine Ausnahme „Sicherungskonto darf zwischen 1:00 und 2:30 Uhr vom Sicherungsserver aus lesend auf die Dateiserver zugreifen“ ist eine Regel, und alles, was davon abweicht, ist ein Alarm.
Die Rufkette: wer um drei Uhr abnimmt
Der dritte Teil ist eine Liste von Namen und Nummern in Reihenfolge. Sie klingt banal und scheitert regelmäßig an drei Dingen: Die erste Nummer ist eine Festnetznummer im Büro. Die zweite Person hat das Haus vor einem halben Jahr verlassen. Die dritte ist der Geschäftsführer, der um drei Uhr nicht entscheiden kann, ob die Warenwirtschaft isoliert werden darf, weil er nicht weiß, was nachts darauf läuft.
Eine Rufkette, die funktioniert, hat drei bis vier Mobilnummern von Menschen, die die Systeme kennen und entscheiden dürfen, eine Vertretungsregel für Urlaub, und sie wird vierteljährlich geprüft – mit einem Testanruf, nicht mit einem Blick auf die Liste. Und sie steht nicht nur beim Anbieter, sondern ausgedruckt an einem Ort, der auch dann erreichbar ist, wenn die eigene IT ausgefallen ist.
Die Liste lebt – oder sie stirbt
Alles oben Beschriebene ist am Tag des Onboardings richtig und sechs Monate später falsch, wenn niemand es pflegt. Ein neuer Server kommt dazu und ist in keiner Klasse. Die Sicherung wechselt die Uhrzeit, und die Ausnahme greift nicht mehr. Ein Dienstleister bekommt ein Konto, das in keiner Ausnahme steht. Der IT-Leiter wechselt, und die Rufkette führt ins Leere.
Deshalb gehört die Liste in die Betreuung, nicht ins Archiv. Bei uns ist sie Teil des vierteljährlichen Berichts: Was ist neu, was hat sich geändert, was wurde angepasst. Das kostet eine Stunde im Quartal. Die Alternative ist eine Erkennung, die nachts auf einer veralteten Karte navigiert – und entweder zu viel anfasst oder zu wenig.
Was das mit dem Preis zu tun hat
Zwei Häuser mit demselben Dienst, derselben Stufe und demselben Preis können völlig verschiedene Nächte erleben. Das eine hat die Liste gepflegt, das andere hat sie abgehakt. Beim ersten isoliert der Analyst um 2:43 Uhr den Dateiserver und lässt die Produktion in Ruhe. Beim zweiten ruft er an, erreicht niemanden und tut nichts – oder isoliert nach bestem Wissen das Falsche. Der Preis des Dienstes ist derselbe. Sein Wert ist es nicht.
Verwandte Themen: Wer hier weiterdenkt, liest bei Angriffserkennung, Überwachung rund um die Uhr und Angriffserkennung ohne eigenes Team weiter.
Quellen
- G DATA MXDR – Managed Extended Detection and Response (Onboarding, Ausnahmen) · G DATA CyberDefense AG
- IT-Grundschutz-Kompendium, Baustein DER.1 Detektion von sicherheitsrelevanten Ereignissen · Bundesamt für Sicherheit in der Informationstechnikamtlich
