Detection Engineering

In großen Unternehmen laufen tausende Computer, Server und Programme. Alle schreiben ständig Protokolle mit: wer sich angemeldet hat, welche Datei geöffnet wurde, welche Verbindung ins Internet ging. Diese Protokolle heißen Logs. Detection Engineering ist die Arbeit, aus dieser Masse an Logs automatisch die verdächtigen Vorgänge herauszufischen. Dafür schreiben Fachleute Regeln, die beschreiben, wie ein Angriff im Protokoll aussieht. Passt ein Vorgang auf eine Regel, löst sie einen Alarm aus, den Menschen prüfen.

Warum Alarme allein noch keine Sicherheit sind

Angriffe scheitern selten daran, dass niemand sie hätte sehen können. Sie scheitern daran, dass die Spuren im Rauschen untergehen. Ein mittelgroßes Unternehmen erzeugt leicht Milliarden Logzeilen pro Tag. Kein Mensch liest das. Ohne gute Regeln bleibt der entscheidende Eintrag einfach liegen.

Das andere Extrem ist genauso gefährlich. Wer zu grob filtert, bekommt hunderte Alarme pro Schicht, die fast alle harmlos sind. Fachleute nennen das Alarmmüdigkeit. Nach der fünfzigsten Fehlwarnung klickt das Sicherheitsteam auch die echte weg. Detection Engineering versucht deshalb, die Zahl der Alarme klein und ihre Trefferquote hoch zu halten.

Dazu kommt ein wirtschaftlicher Punkt. Erkennung ist deutlich billiger als Schadensbehebung. Ein Angriff, der nach zwei Stunden auffällt, kostet ein Unternehmen ein Vielfaches weniger als einer, der monatelang unbemerkt bleibt. Genau deshalb ist die Rolle des Detection Engineers in den letzten Jahren zu einem eigenen Berufsbild geworden.

Von der Angriffsidee zur getesteten Regel

Am Anfang steht nicht die Regel, sondern das Angriffsverhalten. Das Team fragt: Wie geht ein Angreifer konkret vor, wenn er Passwörter aus dem Arbeitsspeicher ausliest? Als Katalog dient meist MITRE ATT&CK, eine öffentliche Sammlung bekannter Angriffstechniken. Aus einer solchen Technik leitet man ab, welche Spur sie in den Logs hinterlässt.

Daraus wird eine Regel formuliert, oft in einem einheitlichen Format wie Sigma oder YARA. Eine simple Regel könnte lauten: Ein Office-Programm startet ein Kommandozeilenfenster. Für ein Textdokument ist das ungewöhnlich, für Schadsoftware in einem Anhang ist es typisch. Solche Regeln laufen dann in einem SIEM, einem System, das alle Logs zentral sammelt und durchsucht.

Entscheidend ist der Teil danach. Die Regel wird gegen echte Angriffssimulationen getestet, im Versionsverwaltungssystem gespeichert und mit einer Dokumentation versehen. Man behandelt sie also wie Programmcode, nicht wie eine Einstellung, die jemand einmal vornimmt. Sobald sich Software, Netzwerk oder Angriffsmethoden ändern, muss die Regel nachgezogen werden. Ein häufiger Irrtum ist, Regeln seien Dauerläufer: Ohne Pflege verlieren sie innerhalb von Monaten ihre Wirkung.

Wo diese Regeln im Alltag greifen

Sichtbar wird die Arbeit meist nur indirekt. Wenn deine Schule den Zugang zu einem Konto sperrt, weil sich jemand aus einem anderen Land angemeldet hat, steckt dahinter eine Erkennungsregel. Auch die Warnung deiner Bank bei einer ungewöhnlichen Zahlung folgt demselben Prinzip. Der Unterschied zum Virenscanner ist wichtig: Ein Scanner sucht nach bekannten Schaddateien, Detection Engineering sucht nach verdächtigem Verhalten.

In Nachrichten taucht das Thema fast immer nach einem großen Hackerangriff auf. Dann heißt es, der Angreifer sei wochenlang unentdeckt im Netz gewesen. Übersetzt bedeutet das: Für diese Vorgehensweise gab es keine passende Regel oder ihr Alarm ging unter.

Künstliche Intelligenz verändert das Feld gerade von zwei Seiten. Sprachmodelle helfen inzwischen beim Entwerfen von Regeln und beim Vorsortieren von Alarmen. Gleichzeitig nutzen Angreifer dieselben Werkzeuge, um ihre Methoden schneller zu variieren. Anbieter wie Microsoft, CrowdStrike oder Elastic verkaufen deshalb nicht nur Software, sondern vor allem gepflegte Regelsammlungen als laufenden Dienst.