KI-Alert-Triage: Alarme vorsortieren, nicht automatisch entscheiden

/01Was KI-Alert-Triage ist — und was sie nicht ist

„KI im SOC" klingt nach einem System, das Angriffe selbstständig erkennt und abwehrt. Das ist nicht, wovon dieser Artikel handelt. KI-Alert-Triage bedeutet etwas Bescheideneres und in der Praxis Nützlicheres: Eine bereits vorhandene Erkennungskette — OPNsense, Suricata, Wazuh — erzeugt Alarme nach festen Regeln, und ein zusätzliches Sprachmodell liest diese Alarme, fasst zusammengehörige Ereignisse zusammen und markiert, was von der gewohnten Baseline einer Umgebung abweicht. Die Erkennung selbst bleibt deterministisch — Regel trifft oder trifft nicht. Die KI arbeitet eine Ebene darüber, auf dem, was die Regeln bereits gemeldet haben.

Diese Abgrenzung ist mehr als Vorsicht in der Wortwahl. Ein SOAR-System automatisiert ganze Reaktionsketten, ein EDR-Agent greift direkt auf dem Endgerät ein — beides sind andere Werkzeuge mit anderem Risiko. KI-Alert-Triage, wie dieser Artikel sie beschreibt, trifft keine Reaktionsentscheidung und greift nicht aktiv ein. Sie sortiert, verdichtet und schlägt vor. Was daraus wird, entscheidet ein Mensch — Abschnitt 06 zeigt, warum diese Grenze bewusst gezogen ist, nicht aus Mangel an technischer Möglichkeit.

Der Anlass für diesen Artikel ist ein ganz praktischer: Ein SIEM, dessen Alarme niemand mehr liest, erkennt im Ergebnis nichts mehr — unabhängig davon, wie gut seine Regeln sind. Die Triage ist ein Versuch, genau diesen Punkt zu verschieben: nicht weniger Alarme erzeugen, sondern die vorhandenen so aufbereiten, dass ein Mensch sie tatsächlich durchsieht, statt sie nach der dritten Routinewoche zu ignorieren.

/02Der Weg der Daten: von eve.json nach Wazuh

Suricata schreibt seine Ereignisse strukturiert als JSON-Zeilen in eine Datei namens eve.json — jede Zeile ein Ereignis, mit Feldern für Quelle, Ziel, Protokoll, ausgelöste Signatur und Schweregrad. Laut Wazuh-Dokumentation genügt ein kurzer Eintrag im Agenten, um diese Datei einzulesen:

# /var/ossec/etc/ossec.conf (Wazuh-Agent)
<ossec_config>
  <localfile>
    <log_format>json</log_format>
    <location>/var/log/suricata/eve.json</location>
  </localfile>
</ossec_config>

Bemerkenswert daran: Die Standardfelder der eve.json werden laut Dokumentation ohne eigenen Decoder erkannt — anders als bei vielen anderen Protokollquellen entfällt hier die sonst übliche Kleinarbeit, Feldnamen manuell zuzuordnen. Im Wazuh-Dashboard lassen sich die eingegangenen Alarme danach gezielt filtern, etwa über rule.groups:suricata, um ausschließlich die netzwerkseitige Erkennung von anderen Protokollquellen wie Windows-Ereignisprotokollen oder Linux-Systemprotokollen zu trennen.

Die eigentliche Pflegearbeit beginnt erst danach: Welche Suricata-Regelgruppen überhaupt aktiv sind, bestimmt, was in der eve.json ankommt — eine Vorfilterung, die nach dieser Datei ansetzt, kann nur mit dem arbeiten, was die Erkennungsebene zuvor bereits entschieden hat zu melden.

Diese Signaturen reagieren teils direkt auf bekannte CVE-Schwachstellen in verbreiteter Software — ein Treffer sagt dann nicht nur „ungewöhnlicher Verkehr", sondern „Verkehrsmuster, das zu einem bekannten Ausnutzungsversuch passt". Diese zusätzliche Information landet mit im Alarm und ist einer der Werte, die eine Triage später beim Priorisieren mitberücksichtigt — ein Treffer mit CVE-Bezug wiegt in der Regel schwerer als ein Treffer ohne.

Technisch bemerkenswert ist außerdem, wie wenig sich an dieser Integration über die Jahre verändert hat: Bereits mit einer deutlich älteren Suricata-Version hat Wazuh denselben Mechanismus in der eigenen Anleitung getestet — dieselbe Konfigurationszeile funktioniert laut Dokumentation unverändert mit aktuellen Suricata-Ständen, ohne dass die Integration selbst gepflegt werden müsste.

Wie ein einzelnes Ereignis in dieser Datei aussieht, zeigt die Suricata-Dokumentation an einem Beispiel aus dem eigenen Format-Handbuch:

{
  "timestamp": "2017-04-07T22:24:37.251547+0100",
  "flow_id": 586497171462735,
  "event_type": "alert",
  "src_ip": "192.168.2.14",
  "dest_ip": "209.53.113.5",
  "proto": "TCP",
  "alert": {
    "action": "allowed",
    "signature_id": 2018358,
    "signature": "ET HUNTING GENERIC SUSPICIOUS POST",
    "category": "Potentially Bad Traffic",
    "severity": 2
  }
}

Jedes Feld hat eine feste Bedeutung: event_type markiert die Zeile als Alarm statt als reines Verbindungsprotokoll, alert.signature_id verweist auf die auslösende Regel, alert.category und alert.severity liefern die Einordnung durch Suricata selbst — eine Skala von 1 bis 3, unabhängig von der 17-stufigen Wazuh-Skala, die im nächsten Abschnitt daraus gebildet wird. Genau diese Felder sind es, die ohne eigenen Decoder direkt im Wazuh-Alarm landen und später die Grundlage für die KI-gestützte Zusammenfassung bilden.

/03Wie Wazuh Alarme bereits vorstuft

Bevor überhaupt eine KI-Komponente ins Spiel kommt, hat Wazuh selbst bereits eine erste Triage vorgenommen. Jede Regel trägt laut Dokumentation einen Schweregrad zwischen 0 und 16: Stufe 0 bedeutet „keine Aktion, dient der Vermeidung von Fehlalarmen", die Standardschwelle fürs Protokollieren liegt bei 3, und ab Stufe 12 — „high importance event" — löst die Standardkonfiguration eine E-Mail-Benachrichtigung aus. Stufe 15 ist für Ereignisse reserviert, bei denen laut Dokumentation praktisch keine Fehlalarm-Wahrscheinlichkeit mehr besteht und sofortiges Handeln nötig ist.

Diese Einstufung ist bereits eine Form von Triage — nur eine starre, regelbasierte. Ein Alarm der Stufe 12 aus einem Portscan auf einem bekannten Testsystem und ein Alarm derselben Stufe 12 aus einer ungewöhnlichen Verbindung zu einer Produktionsdatenbank sind für Wazuh gleich wichtig, obwohl sie es im Kontext der jeweiligen Umgebung nicht sind. Genau an dieser Lücke — gleiche Regelstufe, unterschiedliche tatsächliche Relevanz — setzt die zusätzliche KI-gestützte Triage an.

Diese starre Einstufung ist zugleich der Grund, warum eine reine Regelstufe als alleiniges Kriterium für die Bearbeitungsreihenfolge an Grenzen stößt: Eine Umgebung mit konsequent gepflegtem Regelwerk erzeugt überwiegend relevante Stufe-12-Alarme, eine Umgebung mit vielen ungetunten Signaturen erzeugt denselben Alarm zehnmal am Tag für dasselbe harmlose Muster. Wazuh selbst unterscheidet diese beiden Fälle nicht — aus seiner Sicht ist jeder Treffer der Stufe 12 gleich dringend.

/04Wo KI zusätzlich ansetzt

Ein Sprachmodell, das Zugriff auf die eingestuften Wazuh-Alarme einer Umgebung hat, kann zwei Dinge leisten, die eine starre Regelstufe allein nicht abbildet. Erstens die Verdichtung: Vierzig Einzelalarme eines fünfzigminütigen Portscans aus demselben internen Subnetz werden zu einer Zeile — „Portscan, Quelle intern, Dauer 50 Minuten, keine Treffer auf als kritisch markierten Diensten" — statt vierzig separaten Einträgen, die ein Mensch einzeln aufklappen müsste. Zweitens die Einordnung gegen die Baseline einer konkreten Umgebung: Ist diese Kombination aus Quelle, Zielsystem und Uhrzeit für diesen Kunden ungewöhnlich, oder ist es das wiederkehrende Muster eines bekannten internen Schwachstellen-Scanners?

Wichtig für das Verständnis: Diese Verdichtung arbeitet ausschließlich mit dem, was die Erkennungsebene — Suricata-Signaturen, Wazuh-Regeln — bereits als Ereignis gemeldet hat. Es entsteht keine neue Erkennungsqualität, die über die vorhandene Regelbasis hinausgeht; die KI ordnet, was bereits da ist, in eine Reihenfolge, die ein Mensch zuerst abarbeitet. Ein Angriffsmuster, für das es weder eine Suricata-Signatur noch eine Wazuh-Regel gibt, taucht in der Eingabe für die Triage gar nicht erst auf — die Pflege der Regelbasis bleibt die Grundlage, nicht die Kür.

Ein Alarm von eve.json bis Ticket, durchgespielt

Am Beispiel aus Abschnitt 02 lässt sich die gesamte Kette zeigen. Der rohe Alarm meldet eine verdächtige POST-Anfrage von einem internen Rechner zu einer externen Adresse. Damit dieser Treffer im Wazuh-Dashboard überhaupt auffällt, statt in der allgemeinen Suricata-Gruppe unterzugehen, bekommt er — als Beispiel, nach der von der Wazuh-Dokumentation vorgegebenen Syntax und dem reservierten ID-Bereich 100000 bis 120000 für eigene Regeln — eine eigene Einstufung in local_rules.xml:

# /var/ossec/etc/rules/local_rules.xml (Beispielregel, Syntax nach Wazuh-Dokumentation)
<rule id="100050" level="10">
  <program_name>suricata</program_name>
  <match>ET HUNTING GENERIC SUSPICIOUS POST</match>
  <description>Suricata: verdaechtiger POST-Request von internem Host</description>
</rule>

# Test vor dem Produktiveinsatz, ohne Neustart des Managers:
/var/ossec/bin/wazuh-logtest
# Fuer tatsaechliche Alarme im Betrieb ist laut Dokumentation
# anschliessend ein Neustart des Wazuh-Managers noetig.

Level 10 liegt bewusst unterhalb der Mail-Schwelle von 12 aus Abschnitt 03 — ein einzelner Treffer dieser Art ist meldenswert, aber noch kein Grund für eine nächtliche Benachrichtigung. Erst hier, mit einem bereits eingestuften Wazuh-Alarm, setzt die KI-gestützte Triage an: Sie prüft, ob derselbe interne Host in den letzten Tagen bereits ähnliche Treffer erzeugt hat, ob die Zieladresse in der Umgebung bereits als bekannt und harmlos hinterlegt ist, und verfasst daraus eine Zeile für das Ticketsystem — etwa: „Suricata-Alarm (Regel 100050, Level 10) von internem Host 192.168.2.14 an bisher unbekannte externe Adresse, kein vergleichbarer Treffer in den letzten 30 Tagen, Empfehlung: Herkunft des Datenverkehrs prüfen." Diese Zeile ist ein Vorschlag mit Begründung, keine Ausführung — ob eine Prüfung tatsächlich stattfindet und was sie ergibt, entscheidet wie in Abschnitt 06 beschrieben ein Mensch.

/05Was automatisiert werden kann: Active Response und seine Grenzen

Wazuh bringt mit „Active Response" eine eigene Automatisierungsschicht mit, unabhängig von jeder KI-Komponente: Eine Reaktion — etwa das Sperren einer IP-Adresse über eine Firewall-Regel — lässt sich an eine bestimmte Regel-ID, einen Schweregrad oder eine Regelgruppe koppeln und läuft laut Dokumentation dann automatisch, ohne Rückfrage. Die Dokumentation unterscheidet dabei zustandslose Reaktionen, die einmalig ausgeführt werden, von zustandsbehafteten Reaktionen, die sich nach einer festgelegten Zeit selbst zurücknehmen — eine temporäre Sperrung etwa, die nach einer Stunde automatisch wieder aufgehoben wird.

Das ist technisch leistungsfähig und zugleich der Punkt, an dem Zurückhaltung angebracht ist. Eine automatische Sperrung, die ohne menschliche Bestätigung auslöst, kann im Zweifel auch eine legitime, aber ungewöhnliche Verbindung treffen — ein Außendienstmitarbeiter mit neuer IP-Adresse, ein Dienstleister bei einem angekündigten Wartungseinsatz. Bei HostSpezial ist Active Response deshalb nicht die Standardeinstellung für neu angebundene Umgebungen, sondern eine bewusst eng begrenzte Ausnahme: ausschließlich für Regeln, die über Wochen beobachtet wurden und deren Fehlalarmrisiko bekannt und niedrig ist.

Der Unterschied zur KI-gestützten Triage lässt sich damit klar ziehen: Active Response ist deterministische Automatisierung — dieselbe Bedingung löst immer dieselbe Aktion aus, nachvollziehbar und reproduzierbar. Die Triage ist eine Einschätzung, keine Aktion, und genau deshalb an keiner Stelle mit Active Response gleichzusetzen, auch wenn beide unter dem Oberbegriff „KI im SOC" landen.

Welche Instanz welche Aufgabe übernimmt, lässt sich für die häufigsten Fälle klar aufteilen:

Die mittlere Spalte ist die, die dieser Artikel „KI-Alert-Triage" nennt. Die linke Spalte ist eng begrenzte, vorab geprüfte Automatisierung. Die rechte Spalte bleibt es in jeder Konfiguration, die wir betreiben — unabhängig davon, wie gut eine Empfehlung in der Vergangenheit war.

/06Was KI nicht entscheidet

Die KI-gestützte Triage aus Abschnitt 04 trifft keine Reaktionsentscheidung — sie erzeugt einen Vorschlag mit Begründung, keine Ausführung. Ob eine IP-Adresse gesperrt, eine Firewall-Regel geändert oder ein Vorfall eskaliert wird, entscheidet weiterhin ein Mensch, der den Vorschlag gegen den Kontext prüft, den eine Maschine nicht hat: Läuft gerade eine angekündigte Wartung, ist die Quelle eine bekannte Außenstelle, passt das Muster zu einem harmlosen internen Werkzeug? Diese Freigabe durch einen Menschen gilt unabhängig davon, ob die Triage einen Befund als dringend oder als unauffällig einordnet.

Diese Grenze ist auch deshalb wichtig, weil ein Sprachmodell selbst Fehler macht — anders geartete Fehler als eine starre Regel, aber nicht weniger real. Es kann einen Zusammenhang zwischen zwei Ereignissen herstellen, der zufällig ist, oder eine Abweichung als harmlos einordnen, weil sie oberflächlich einem bekannten Muster ähnelt, es tatsächlich aber nicht ist. Eine Entscheidung, die eine Firewall-Regel ändert oder ein System isoliert, verdient deshalb dieselbe menschliche Prüfung wie vor der Einführung der Triage — die Triage ändert, wie schnell ein Mensch bei der relevanten Information ankommt, nicht, dass er am Ende entscheidet.

/07Fehlalarme senken: Schwellenwerte und Baseline

Fehlalarme lassen sich auf zwei Ebenen dämpfen, die sich ergänzen, nicht ersetzen. Auf der Erkennungsebene kennt Suricata mehrere Grenzwerttypen: Der Typ „threshold" erzeugt laut Dokumentation erst ab einer bestimmten Trefferzahl einen Alarm, im Beispiel count 10, seconds 60 — zehn gleichartige Treffer in einer Minute, bevor überhaupt etwas gemeldet wird. Gezählt werden kann dabei nach Quelladresse, Zieladresse, dem Paar aus beiden, der einzelnen Signatur oder dem konkreten Datenfluss, je nachdem, welches Muster tatsächlich interessant ist.

# Beispielsyntax aus der Suricata-Dokumentation
threshold gen_id 1, sig_id 2010935, type threshold, track by_src, count 10, seconds 60

Auf der Triage-Ebene kommt die Baseline hinzu, die in Abschnitt 04 beschrieben wurde: Ein Muster, das für eine Umgebung seit Monaten alltäglich ist — ein nächtlicher Scan durch das eigene Monitoring-Werkzeug etwa —, wird nach einer Einlaufzeit als bekannt erkannt und entsprechend niedriger priorisiert, ohne komplett zu verschwinden. Beide Ebenen zusammen verhindern, dass ein Alarmkanal in Routine erstickt: die Schwellenwerte dämpfen auf Netzwerkebene, die Baseline sortiert auf Auswertungsebene. Keine der beiden Ebenen ersetzt die andere — eine zu grob eingestellte Suricata-Signatur erzeugt so viel Rauschen, dass selbst die beste Triage nur noch Rauschen priorisiert.

/08Wo es hakt

Drei Punkte, die vor dem produktiven Einsatz auf den Tisch gehören.

Ohne Baseline ist die Triage blind

Für eine neu angebundene Umgebung existiert noch kein gelernter Normalzustand. In den ersten Wochen priorisiert die Triage entsprechend grober, weil ihr die Vergleichsbasis fehlt — das ist eine Einlaufzeit, keine dauerhafte Schwäche, aber sie sollte vor dem ersten produktiven Einsatz offen benannt werden, nicht erst, wenn ein Kunde eine ausbleibende Markierung bemängelt.

Automatisierte Reaktion ist ein Risiko, das aktiv begrenzt werden muss

Wie in Abschnitt 05 beschrieben, kann Active Response technisch ohne Rückfrage auslösen. Wer diese Funktion breiter einsetzt, als die eigene Erfahrung mit der jeweiligen Regel trägt, riskiert, legitimen Verkehr zu blockieren — ein Fehler, der im Zweifel schneller auffällt als ein ausbleibender Alarm, aber nicht weniger störend ist.

Ein Sprachmodell erklärt nicht immer korrekt, warum es priorisiert hat

Die Begründung, die eine Triage zu einem Vorschlag liefert, ist eine plausible Formulierung, keine beweisbare Herleitung im Sinn einer Log-Analyse Schritt für Schritt. Wer eine Entscheidung ausschließlich auf die Begründung der KI stützt, statt die zugrunde liegenden Rohereignisse im Zweifel selbst zu prüfen, verlässt sich auf etwas, das korrekt klingt, aber nicht in jedem Fall korrekt sein muss.

Alarmdaten enthalten personenbezogene Informationen

IP-Adressen, gelegentlich auch Benutzernamen aus Authentifizierungsereignissen, sind personenbezogene oder zumindest personenbeziehbare Daten im Sinn der DSGVO — daran ändert sich nichts dadurch, dass ein Sprachmodell sie verarbeitet statt ein Mensch. Die Triage-Pipeline läuft deshalb innerhalb der eigenen Infrastruktur im Rechenzentrum Coburg mit Ausweichstandort Neustadt, dokumentiert als technische und organisatorische Maßnahme im Rahmen der ISO/IEC 27001:2024-Zertifizierung (Zertifikat 202787, gültig bis 05.09.2029) — nicht als Aufruf an einen externen Dienst mit unklarem Verarbeitungsort.

/09Wann sich KI-gestützte Triage lohnt — und wann nicht

KI-gestützte Triage ist kein Ersatz für eine gepflegte Regelbasis und keine Lösung für eine Umgebung, die noch gar keine strukturierte Alarmauswertung hat.

Dafür spricht

• Ein SIEM, das bereits läuft, aber dessen Alarme kaum gelesen werden: Die Verdichtung macht den Unterschied zwischen einem Alarmkanal, der nebenbei mitläuft, und einem, der tatsächlich ausgewertet wird.
• Mehrere angebundene Umgebungen mit unterschiedlicher Normalität: Eine Baseline je Kunde oder Standort verhindert, dass dieselbe Regelstufe überall gleich priorisiert wird, obwohl die Relevanz unterschiedlich ist.
• Vorhandene Incident-Response-Prozesse, die nur an mehr Zeit scheitern: Die Triage spart Lesezeit, nicht Entscheidungszeit — wo die Entscheidungswege bereits stehen, zahlt sich das am stärksten aus.

Dagegen spricht

• Eine Regelbasis, die selbst noch nicht gepflegt ist: Triage auf einer unausgereiften Erkennungsebene priorisiert zuverlässig falsch — zuerst gehört die Regelbasis in Ordnung, dann die Priorisierung darüber.
• Die Erwartung eines autonomen SOC: Wer eine Lösung sucht, die selbstständig erkennt, entscheidet und reagiert, sucht ein anderes Produkt als das hier beschriebene — die Entscheidung bleibt beim Menschen, siehe Abschnitt 06.
• Fehlende Kapazität, Vorschläge überhaupt zu bearbeiten: Eine priorisierte Liste, die niemand abarbeitet, ist nicht besser als eine unsortierte — die Triage ersetzt keine Runbook-gestützte Reaktion, sie setzt sie voraus.

Unsere Praxis-Linie: Regelbasis zuerst, Baseline zweitens, Automatisierung einzelner Reaktionen zuletzt und nur für geprüfte Fälle. KI-gestützte Triage verkürzt den Weg zur richtigen Priorität — sie ersetzt nicht die Arbeit, die Regeln und Prozesse dahinter brauchen. Als Teil unseres Managed Service für Wazuh steht die Triage deshalb nie isoliert, sondern neben der laufenden Regelpflege, die den Unterschied macht, ob am Ende weniger Zeit bis zur richtigen Einschätzung vergeht (verkürzte Wiederherstellungszeit) oder nur mehr Text in derselben Alarmflut steht.

/10Häufige Fragen