Intrusion-Detection-Systeme bewegen sich von einer nahezu vollständigen Abhängigkeit von bekannten Signaturen hin zu einer hybriden Architektur, die traditionelle Mustererkennung, maschinelles Lernen und agentische Untersuchungen kombiniert. Eine auf dem Stack-Overflow-Blog veröffentlichte Analyse betrachtet SnortML als eine niedrig liegende Sensorikschicht innerhalb von Snort 3, während agentische künstliche Intelligenz Ereignisse über Zeit und Quellen hinweg verknüpft und den nächsten Untersuchungsschritt bestimmt.
Das Problem traditioneller Signaturen besteht nicht darin, dass sie ungenau wären, sondern darin, dass sie präzise auf das reagieren, wofür sie entwickelt wurden. Eine Regel für eine bestimmte Schwachstelle wie CVE-2024-12345 kann eine bekannte Ausnutzung mit einer sehr niedrigen Rate an Fehlalarmen erkennen, reagiert aber möglicherweise nicht auf eine veränderte Payload, die denselben anfälligen Codepfad durchläuft. Zwischen dem Auftreten eines neuen Exploits in freier Wildbahn, seiner Analyse, dem Schreiben und Testen einer Regel sowie ihrer Verteilung können Tage oder Wochen vergehen – eine gefährliche Lücke, wenn die Schwachstelle tatsächlich ausgenutzt wird.
Wie arbeitet SnortML innerhalb von Snort 3?
Cisco Talos stellte die SnortML-Engine im März 2024 als Machine-Learning-Erkennungs-Engine vor, die nativ innerhalb von Snort 3 arbeitet. Die Engine ist nicht auf einen externen Cloud-Dienst angewiesen, da die Inferenz lokal innerhalb desselben Verarbeitungspfads erfolgt, der auch zur Auswertung der Regeln verwendet wird, und innerhalb von weniger als einer Millisekunde ein Ergebnis liefert.
Die Implementierung besteht aus dem Modul snort_ml_engine, das die vortrainierten TensorFlow-Modelle beim Start lädt, und dem Inspector snort_ml, der Daten über eine Publish-and-Subscribe-Schnittstelle von den vorhandenen Service-Inspectors in Snort 3 empfängt. Wenn der HTTP-Inspector die Analyse einer Anfrage beendet, sendet er die Query-Zeichenfolge und den POST-Inhalt an den Event-Bus. SnortML klassifiziert sie anschließend und gibt einen Wahrscheinlichkeitswert zurück, der auf die Wahrscheinlichkeit hinweist, dass sie einen Exploit-Versuch enthält.
Das Modell basiert auf einem LSTM-Netzwerk, dem eine Embedding-Schicht vorgeschaltet ist, die rohe Bytewerte in Vektordarstellungen umwandelt. Dadurch können Beziehungen und Kontext zwischen Bytes erfasst werden, bevor das LSTM ihre Reihenfolge und Sequenz verarbeitet. Eine abschließende Dense-Schicht reduziert das Ergebnis auf einen einzigen Wahrscheinlichkeitswert. LibML, das zusammen mit SnortML bereitgestellt wird, verwendet die XNNPACK-Bibliothek zur Beschleunigung von Matrixoperationen. Laut dem Artikel dauert eine einzelne Klassifizierung auf einem AMD-Prozessor mit 4,7 GHz ungefähr 350 Mikrosekunden.
Ab Secure Firewall 10.0.0 wählt SnortML automatisch ein passendes Modell für Längen von 256, 512 oder 1024 Bytes aus. Anfragen, die 1024 Bytes überschreiten, werden vor der Klassifizierung an dieser Grenze abgeschnitten. Die erste Version begann mit der Erkennung von SQL-Injection. Bis Ende 2025 wurde die Abdeckung auf XSS und Command Injection ausgeweitet. Modellaktualisierungen werden über dasselbe Lightweight Security Package-System bereitgestellt, das auch zur Verteilung von Regelinhalten verwendet wird.
Stärken und Grenzen des hybriden Ansatzes
SnortML arbeitet parallel zur Signaturerkennung, nicht als deren Ersatz. Das Modell kann neue Varianten von Angriffen erkennen, die in bekannte Kategorien fallen, während traditionelle Signaturen eine rauscharm arbeitende Linie für bestätigte Muster bieten. Wenn beide Pfade bei derselben Payload einen Alarm auslösen, kann dies als stärkeres Signal betrachtet werden als ein Alarm, der ausschließlich vom maschinellen Lernen stammt, wobei jede Methode weiterhin unterschiedliche Fehlereigenschaften aufweist.
SnortML analysiert jedoch einen einzelnen HTTP-Parameter, beispielsweise eine URI-Query-Zeichenfolge oder einen POST-Inhalt, und weiß nicht, was vor oder nach der Anfrage geschehen ist oder was die Quelladresse in den vorangegangenen Minuten getan hat. Daher kann eine Sequenz aus Aufklärung, Enumeration und einem maßgeschneiderten Exploit unentdeckt bleiben, wenn kein einzelner Schritt die Erkennungsschwelle überschreitet. Das aktuelle Modell erkennt außerdem weder DNS-Tunneling noch TLS-Angriffe, SMB-Exploits oder anomales Verhalten in Nicht-HTTP-Protokollen, da die verfügbaren Modelle an den Datenpfad des HTTP-Inspectors gebunden sind.
Die Verarbeitungszeit von etwa 350 Mikrosekunden verursacht zudem reale Kosten, auch wenn diese dank XNNPACK begrenzt und vorhersehbar sind. Deshalb sollte die Leistung des Modells nicht losgelöst von der Größe des Regelwerks, der Komplexität der Protokolle und dem Verarbeitungsbudget des Schutzgeräts betrachtet werden.
Was fügt agentische künstliche Intelligenz hinzu?
Die Analyse unterscheidet zwischen einem Machine-Learning-Modell, das nur das unmittelbar vorliegende Material bewertet, einem SOAR-Runbook, das festgelegte Schritte ausführt, und einem Agenten, der einen mehrstufigen Untersuchungszustand beibehält und anhand früherer Ergebnisse entscheidet, was als Nächstes geprüft werden sollte. Der Agent kann dem vorgestellten Konzept zufolge das SIEM nach zugehörigen Ereignissen abfragen, den Hash einer Datei über eine Threat-Intelligence-Plattform prüfen, Benutzeraktivitäten beim Identitätsanbieter abrufen und anschließend den Kontext zusammenführen, bevor er eine Reaktion empfiehlt oder sie an einen menschlichen Analysten weiterleitet.
Der Artikel verweist auf die Einführung der ATOM-Plattform, der Autonomous Threat Operations Machine, durch IBM im April 2025 sowie auf die Einführung von Agentic SIEM durch Trend Micro im August 2025. Diese Systeme werden als Plattformen für die Koordination und Untersuchung durch mehrere Agenten dargestellt, nicht lediglich als Konversationsschnittstellen mit Sicherheitsinformationen. Die Analyse führt ihre Verbreitung auf den Druck durch den Fachkräftemangel zurück. Sie nennt eine weltweite Lücke von ungefähr vier Millionen unbesetzten Stellen im Bereich Cybersicherheit sowie eine Umfrage aus dem Jahr 2025, der zufolge 82 % der Analysten in Security Operations Centern befürchten, aufgrund des Alarmvolumens echte Bedrohungen zu übersehen.
In dieser Architektur werden Snort 3 und SnortML zu netzwerknahen Sensoren, die das tatsächlich Beobachtete an die übergeordnete Inferenzschicht liefern. Der höhere Automatisierungsgrad macht die Genauigkeit der Sensorik jedoch wichtiger: Ein Fehlalarm beansprucht nicht nur die Zeit des Analysten, sondern auch Ressourcen der Agenten und kann in schlecht konfigurierten Umgebungen Eindämmungsmaßnahmen auslösen. Der Wahrscheinlichkeitswert von SnortML ermöglicht außerdem die Bildung eines kombinierten Vertrauenswerts. Ein Alarm, der eine traditionelle Signatur mit einem ML-Wert von 0,97 verbindet, sollte anders behandelt werden als ein Alarm, der ausschließlich vom ML mit einem Wert von 0,61 ausgelöst wurde.
Integrationsarchitektur und das Problem der Rückkopplungsschleife
Der Artikel schlägt eine Architektur vor, die mit einer Paketerfassungsschicht über DAQ beginnt und je nach Durchsatzanforderungen AFPacket RSS oder DPDK verwendet. Darauf folgt eine Erkennungsschicht, die die MPSE-Hyperscan-Engine und SnortML parallel ausführt. Beide Schichten senden Ereignisse im JSON-Format, einschließlich Alarmen, Wahrscheinlichkeitswerten und Flow-Daten, an einen einheitlichen Messdatenbus.
Anschließend werden die Aufgaben auf spezialisierte Agenten verteilt: einen Agenten für Triage, Deduplizierung und Risikobewertung, Agenten für Anreicherung und Threat Intelligence, einen Untersuchungsagenten, der SIEM-Protokolle, den Identitätsanbieter und Endpoint-Daten miteinander verknüpft, sowie einen Kontextagenten, der die Aktivität mit historischen Mustern und bekannten Kampagnen vergleicht. Das Konzept betont, dass bestätigte Untersuchungsergebnisse an die Modell- und Regel-Engines zurückgeführt werden müssen, anstatt den Datenfluss bei der Reaktionsphase enden zu lassen.
Payloads, die als Angriffe bestätigt wurden, aber einen niedrigen Wert erhalten oder keiner Signatur entsprachen, können in Trainingsdaten oder Eingaben für die Erstellung neuer Regeln umgewandelt werden. Dieser Prozess erfordert jedoch eine menschliche Validierung und Mechanismen zur Erkennung einer Vergiftung der Trainingsdaten, da ein Angreifer versuchen könnte, die Ergebnisse der automatisierten Untersuchung zu manipulieren, um fehlerhafte Beispiele in den erneuten Trainingsprozess einzuschleusen.
Bereitstellungsbeschränkungen und praktische Empfehlungen
Die Analyse stellt weitere Lücken fest, darunter die derzeitige Beschränkung der SnortML-Abdeckung auf HTTP-Parameter, die fehlende Reife von Protokollen zur Koordination von Agenten und die geringe Interpretierbarkeit von Modellalarmen. Die aktuellen Ausgaben zeigen den Wahrscheinlichkeitswert und die Payload, die den Alarm ausgelöst hat, erklären jedoch nicht, welche Bytes oder Bereiche der Eingabe das Ergebnis beeinflusst haben. Auch die Robustheit des Modells gegenüber Verschleierung, Kodierung, Manipulation von Leerzeichen und dem Einschleusen von SQL-Kommentaren wurde laut Artikel in veröffentlichten Bewertungen nicht öffentlich beschrieben.
Praktisch empfiehlt der Artikel, SnortML an einem Überwachungsport und zunächst nur im Alarmmodus zu betreiben, nicht direkt im Datenpfad mit aktivierter Blockierung. Falschmeldungen sollten mindestens zwei Wochen lang anhand des Datenverkehrs bekannter Anwendungen gemessen werden, wobei die üblichen Arbeitszyklen abgedeckt werden. Anschließend sollten die Schwellenwerte angepasst werden, bevor eine selektive Inline-Bereitstellung aktiviert wird. Außerdem sollte der ML-Score als ein Faktor innerhalb einer kombinierten Vertrauensbewertung behandelt werden, nicht als Ersatz für die herkömmliche Signatur oder als alleiniger Auslöser für eine Blockierung.
Maßnahmen zur Eindämmung mit weitreichenden Auswirkungen, etwa das Blockieren von IP-Adressen, die Isolation von Geräten oder das Zurücksetzen von Zugangsdaten, sollten weiterhin einer menschlichen Überprüfung unterliegen. Die zentrale Schlussfolgerung der Analyse lautet, dass die Automatisierung Sortierung, Anreicherung, Korrelation und die umfassende Zusammenführung des Kontexts übernehmen kann, während die endgültige Reaktionsentscheidung sicherer bleibt, wenn sie von einem Menschen auf Grundlage des vom Agenten zusammengetragenen Kontexts überprüft wird.