KI-gestützte Anomalieerkennung: Warum Erklärbarkeit wichtiger ist als Genauigkeit

Stell dir vor, dein SIEM meldet einen kritischen Alert. Das zugrunde liegende KI-Modell ist zu 97% sicher, dass hier etwas nicht stimmt. Du öffnest den Alert. Das Modell nennt dir die Entscheidung, aber nicht die Begründung.

Was machst du damit?

Das Problem mit Black-Box-Modellen

KI-gestützte Anomalieerkennung ist im Security-Bereich längst angekommen. Viele SIEM- und UEBA-Plattformen nutzen Modelle, die aus Verhaltensdaten Anomalien erkennen. Das ist nützlich. Aber es bringt ein spezifisches Problem mit sich.

Klassische Regelwerke sind transparent. Eine Regel sagt: "Alert wenn ein Account außerhalb der Geschäftszeiten auf einen Fileserver zugreift." Der Analyst versteht sofort, was den Alert ausgelöst hat, und kann einschätzen ob es relevant ist.

Ein unsupervised Deep-Learning-Modell sagt: "Diese Aktivität ist anomal (Score: 0.94)." Warum ist sie anomal? Welche Features haben das Modell zu dieser Einschätzung gebracht? Das Modell schweigt.

Das ist nicht nur ein ästhetisches Problem. Es ist ein operatives.

Was DeepAID löst

Ein Forschungsteam hat 2021 auf der ACM CCS ein Framework namens DeepAID vorgestellt. Die Ausgangsfrage war direkt: Wenn Deep-Learning-Modelle in Security-Anwendungen Anomalien erkennen, wie erklärt man einem Analysten, was das Modell gesehen hat?

DeepAID ist kein neues Modell. Es ist eine Erklärungsschicht für bestehende Modelle. Es wurde auf drei realen Security-Systemen getestet: Netzwerk-Anomalieerkennung, Log-Anomalieerkennung und Threat Intelligence.

Das Ergebnis: Analysten konnten mit Erklärungen deutlich schneller und sicherer entscheiden ob ein Alert relevant ist. Nicht weil das Modell besser wurde, sondern weil sie verstanden warum das Modell angeschlagen hat.

Warum das für Threat Hunter relevant ist

Threat Hunter sind keine passiven Alert-Konsumenten. Sie stellen Hypothesen auf und suchen Belege. Für diese Arbeit brauchen sie nicht nur das Signal, sie brauchen den Kontext.

Ein KI-System, das sagt "anomaler Netzwerkverkehr auf Port 443 von Host X", ist ein Ausgangspunkt. Ein System, das sagt "anomaler Netzwerkverkehr auf Port 443 von Host X, weil dieser Host normalerweise nur mit drei internen Servern kommuniziert und heute 47 externe Verbindungen aufgebaut hat", ist ein Arbeitswerkzeug.

Der zweite Satz erlaubt dem Threat Hunter eine Entscheidung. Er kann die 47 externen Verbindungen prüfen, eine Hypothese formulieren und den Hunt beginnen. Der erste Satz stellt ihn vor eine Black Box.

Die Genauigkeit ist nicht das entscheidende Kriterium

Das klingt kontraintuitiv. Genauigkeit ist doch das, wofür Modelle optimiert werden.

Aber in Security-Kontexten trifft man auf ein spezifisches Problem: False Positives sind teuer. Nicht weil sie harmlos sind, sondern weil sie Analysten-Zeit verbrauchen. Ein Modell mit 99% Genauigkeit, das seine Entscheidungen nicht erklären kann, produziert trotzdem Alerts, die ein Mensch untersuchen muss. Und wenn der Mensch nicht versteht warum der Alert entstanden ist, wird er ihn entweder zu schnell schließen oder zu lange untersuchen.

Erklärbarkeit reduziert den kognitiven Aufwand pro Alert. Das macht Analysten schneller und damit das Gesamtsystem effektiver, unabhängig von der Modellgenauigkeit.

Was das für die Praxis bedeutet

Wenn du KI-gestützte Erkennung in deiner Umgebung betreibst oder evaluierst, ist Erklärbarkeit eine relevante Anforderung. Fragen die du stellen solltest:

Kann das System erklären, warum ein Alert entstanden ist? Nicht auf Regelebene ("Regel 4711 hat angeschlagen"), sondern auf Verhaltensebene: Welches beobachtete Verhalten weicht wie stark vom Normalverhalten ab?

Kann ein Analyst die Erklärung verwenden? Eine Erklärung die nur ein Data Scientist lesen kann, ist für den SOC-Betrieb wertlos. Die Erklärung muss operativ nutzbar sein.

Wie wird das Baseline-Modell aktuell gehalten? Anomalieerkennung basiert auf einem Modell des Normalzustands. Dieser Normalzustand ändert sich. Nach einer Systemmigration, nach einem Reorganisationsprojekt, nach dem Onboarding einer neuen Niederlassung. Ein Modell, das nicht aktualisiert wird, wird zunehmend ungenau.

Die Verbindung zu Threat Hunting

Threat Hunting und KI-gestützte Erkennung sind keine Konkurrenten. Sie ergänzen sich, wenn die Schnittstelle stimmt.

Die automatisierte Erkennung liefert Signale. Der Threat Hunter untersucht die interessantesten davon und entwickelt neue Hypothesen. Diese Hypothesen können in neue Regeln oder Modell-Updates einfließen. Das ist der Analyse-Loop aus Episode 3 dieser Serie in der Praxis.

Damit dieser Loop funktioniert, muss der Threat Hunter die Signale verstehen, die er untersucht. Dafür braucht er Erklärbarkeit.

Meine Meinung ist

Ein KI-Modell, das Anomalien findet, ohne erklären zu können warum, schafft Mehrarbeit. Es produziert Alerts, die ein Mensch untersuchen muss, ohne den nötigen Kontext zu liefern.

Erklärbarkeit ist kein akademisches Luxusproblem. Sie ist eine operative Anforderung für jede KI-gestützte Sicherheitslösung, die von echten Analysten in echten Umgebungen genutzt wird.

Wenn du KI im SOC einführst: Frag nicht nur "Wie genau ist es?" Frag auch: "Kann mein Team verstehen, was das System sieht?"