Lokales Qwen-Modell unterstützt Security-Operations-Lab mit Wazuh
Ein selbst aufgebautes SOC-Labor kombiniert Wazuh mit dem lokal betriebenen Modell Qwen, um aus der Masse an Sicherheitsmeldungen relevante Ereignisse herauszufiltern und einzuschätzen. Die Umsetzung zeigt, dass Alerts sammeln nur der Anfang ist, die eigentliche Herausforderung die fundierte Auswertung bleibt.
Veröffentlicht am 24. Oktober • Zuerst erschienen auf ta551.info • KI-unterstützt
Security-Monitoring erzeugt eine große Menge an Daten. Doch das Sammeln von Alerts ist nur der Anfang. Die eigentliche Herausforderung besteht darin, die richtigen Ereignisse abzurufen, zu verstehen, was geschehen ist, und auf Grundlage von Belegen Entscheidungen zu treffen.
Ich wollte einer praktischen Frage nachgehen:
Kann ein lokal gehostetes KI-Modell einem Security-Analysten dabei helfen, Wazuh-Alerts zu untersuchen, ohne dass die KI die Kontrolle über die Infrastruktur erhält?
Um das zu ergründen, habe ich ein isoliertes KI-gestütztes Security Operations Center (SOC) Labor mit Wazuh, OpenSearch, Python, SQLite und einem lokalen Qwen-Modell aufgebaut.
Es handelt sich um einen manuell betriebenen Proof of Concept, nicht um eine produktive SOC oder eine autonome Sicherheitsplattform.
Die Umgebung umfasst Ubuntu-24.04-Virtualmaschinen für Security-Telemetrie und Wazuh-Dienste sowie eine Windows-Workstation, auf der der Python-Assistent und LM Studio laufen.
Der Assistent verwendet ein eingeschränktes Lese-Konto. Der Zugriff auf den Indexer ist über SSH-Port-Weiterleitung und TLS-Verifizierung abgesichert.
Wichtige Sicherheitsgrenze: Die KI kann keine Firewall-Befehle ausführen, keine Serverkonfigurationen ändern und keine IP-Adressen automatisch blockieren.
Ihr Zweck ist die Untersuchungsunterstützung, nicht die autonome Behebung.
Meine erste Implementierung rief lediglich die 20 neuesten Alerts ab.
Das funktionierte für eine kleine Demonstration, war aber nicht zuverlässig, wenn mehr Ereignisse vorlagen.
Ich verbesserte den Python-Client mithilfe der OpenSearch-Scroll-Paginierung, um einen begrenzten Schnappschuss der übereinstimmenden Alerts abzurufen.
152 übereinstimmende Alerts wurden von OpenSearch gemeldet.
Das bestätigte, dass die Paginierungslogik für diesen Abfrage-Schnappschuss korrekt funktionierte.
Es bewies weder ein kontinuierliches Monitoring noch eine vollständige historische Abdeckung.
Außerdem stieß ich auf ein Indexer-Berechtigungsproblem, das die Scroll-Bereinigung betraf. Die Korrektur der Leser-Berechtigungen gehörte dazu, den Workflow zuverlässig zu machen, ohne ihm unnötigen Zugriff zu gewähren.
Ursprünglich wurden verarbeitete Ereignis-IDs in einer JSON-Datei verfolgt.
Dieser Ansatz war einfach, aber ich wollte eine zuverlässigere Verwaltung des Ereigniszustands sowie Recovery- und Retry-Verhalten.
Ich führte SQLite ein, um verarbeitete Kennungen und Incident-Berichte dauerhaft zu speichern.
Während der Verifizierung migrierte ich erfolgreich 20 vorhandene Ereignis-IDs und bestätigte die Datenbankintegrität.
Ich testete außerdem die Wiederherstellung eines synthetischen Incident-Berichts aus der Datenbank, nachdem dessen Markdown-Export gefehlt hatte.
Das lehrte mich eine wichtige ingenieurstechnische Lektion:
Die KI-Analyse ist nur ein Teil des Systems. Ein zuverlässiger Ereigniszustand und Recovery sind ebenso wichtig.
Der Python-Assistent verbindet sich über den lokalen API-kompatiblen Endpunkt von LM Studio mit Qwen.
Der Workflow sendet ausgewählte Sicherheitsereignisse an das Modell und fordert eine strukturierte JSON-Ausgabe an.
Die Anwendung validiert die erforderlichen Felder, bevor ein Bericht gespeichert wird.
In einem Test verwendete ich ein synthetisches fehlgeschlagenes SSH-Authentifizierungsereignis.
Empfohlene Maßnahme: Untersuchen und prüfen Sie die zugehörigen Protokolle.
Das war nützlich, mir fiel aber auch auf, wie leicht ein Sprachmodell den technischen Kontext missverstehen kann.
Beispielsweise kann ein Client-Quellport mit einem Ziel-Dienstport verwechselt werden. Ein einzelner fehlgeschlagener Login deutet zudem nicht automatisch auf Brute-Force-Aktivität hin.
Deshalb trenne ich die beobachteten Belege von den KI-generierten Hypothesen.
Eines der interessantesten Experimente betraf eine nicht vertrauenswürdige SSH-Lognachricht.
Ich testete synthetische Protokollinhalte, die Text enthielten, der darauf ausgelegt war, das Modell dazu zu bringen, eine fehlgeschlagene Authentifizierung als erfolgreiche Authentifizierung zu behandeln.
In einem dokumentierten Nachtest bewahrte das Modell den Befund des fehlgeschlagenen Logins.
Ein früherer Test offenbarte außerdem eine unsichere Empfehlung, eine IP-Adresse zu blockieren. Ich führte eine konservative Filterung der Empfehlungen sowie Regressionstests ein, um die Antworten im Rahmen der Read-only-Untersuchung des Labors zu halten.
Diese demonstrieren keine vollständige Widerstandsfähigkeit gegen Prompt-Injection und garantieren nicht, dass jede KI-generierte Empfehlung sicher ist.
Sicherheitsprotokolle sind Belege, keine Anweisungen.
Ich wollte, dass das Projekt mehr demonstriert als einen funktionierenden Screenshot.
Das Repository enthält 31 gemockte und offline ausgeführte Python-Tests, die über GitHub Actions mit Python 3.10 und 3.12 ausgeführt werden.
Die Implementierung umfasst außerdem die Validierung der Ereignisidentität, einen persistenten Verarbeitungsstatus, strukturierte Modellantworten und rein lesende operationale Grenzen.
Allerdings beweisen automatisierte Tests allein weder die Sicherheit im Produktivbetrieb noch die Genauigkeit der Erkennung.
Das Labor hat weiterhin wichtige Einschränkungen: manuelle Ausführung, keine kontinuierliche Alarmüberwachung sowie Netzwerkbeschränkungen rund um den lokalen Modelldienst, die vor einer breiteren Bereitstellung einer weiteren Überprüfung bedürfen.
Aus diesem Projekt lassen sich drei Erkenntnisse hervorheben.
Erstens kommt eine zuverlässige Datenabfrage vor jeder KI-Analyse. Fehlende Alarme können selbst einen gut geschriebenen Vorfallbericht untergraben.
Zweitens kann eine lokale KI Sicherheitsuntersuchungen unterstützen, doch ihre Ergebnisse müssen validiert werden. Eine strukturierte Antwort ist nicht zwangsläufig eine korrekte Antwort.
Drittens braucht Automatisierung klare Sicherheitsgrenzen. Ich bevorzuge ein System, das einem Analysten hilft, ein Ereignis zu verstehen, gegenüber einem, das ohne Genehmigung potenziell schädliche Aktionen ausführt.
Meine nächsten Arbeitsschwerpunkte umfassen realistischere Alarm-Replay-Tests, bessere Leistungsmessungen und strengere Netzwerkbeschränkungen für das lokale Modell.
Das öffentliche Repository enthält die Python-Implementierung, Tests, Dokumentation und anonymisierte Verifikationsbeispiele.
Originaler Fachartikel: Building a Local AI SOC Lab with Wazuh and Qwen.
Mich interessiert, wie andere Ingenieure lokale KI für Security Operations angehen.
Würden Sie einem lokalen LLM vertrauen, Berichte für das Incident Triage vorzubereiten, wenn jede Empfehlung eine menschliche Freigabe erfordert?
Redaktioneller Hinweis: Diese DEV.to-Adaption wurde mit KI-Unterstützung beim Verfassen erstellt, wobei mein ursprünglicher Fachartikel und die dokumentierten Projektergebnisse als Quellmaterial dienten.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 24 • Originally published at ta551.info • AI-assisted
Security monitoring generates a lot of data. But collecting alerts is only the beginning. The real challenge is retrieving the right events, understanding what happened, and making decisions based on evidence.
I wanted to explore a practical question:
Can a locally hosted AI model help a security analyst investigate Wazuh alerts without giving the AI control over the infrastructure?
To explore this, I built an isolated AI-assisted Security Operations Center (SOC) lab using Wazuh, OpenSearch, Python, SQLite, and a local Qwen model.
This is a manually operated proof of concept, not a production SOC or an autonomous security platform.
The environment includes Ubuntu 24.04 virtual machines for security telemetry and Wazuh services, together with a Windows workstation running the Python assistant and LM Studio.
The assistant uses a restricted reader account. Access to the Indexer is protected through SSH port forwarding and TLS verification.
Important security boundary: The AI cannot execute firewall commands, modify server configurations, or automatically block IP addresses.
Its purpose is investigation support, not autonomous remediation.
My initial implementation retrieved only the 20 newest alerts.
This worked for a small demonstration, but it was not reliable when more events were present.
I improved the Python client using OpenSearch Scroll pagination to retrieve a bounded snapshot of matching alerts.
152 matching alerts were reported by OpenSearch.
That confirmed the pagination logic worked correctly for that query snapshot.
It did not prove continuous monitoring or complete historical coverage.
I also encountered an Indexer permission issue affecting Scroll cleanup. Fixing the reader permissions was part of making the workflow reliable without giving it unnecessary access.
Originally, processed event IDs were tracked using a JSON file.
That approach was simple, but I wanted more reliable event state, recovery, and retry behavior.
I introduced SQLite to preserve processed identifiers and incident reports.
During verification, I successfully migrated 20 existing event IDs and confirmed database integrity.
I also tested restoring a synthetic incident report from the database after its Markdown export was missing.
This taught me an important engineering lesson:
AI analysis is only one part of the system. Reliable event state and recovery matter just as much.
The Python assistant connects to Qwen through LM Studio's local API-compatible endpoint.
The workflow sends selected security events to the model and requests structured JSON output.
The application validates required fields before saving a report.
In one test, I used a synthetic failed SSH authentication event.
Recommended action: Investigate and review related logs.
This was useful, but I also noticed how easily a language model could misinterpret technical context.
For example, a client source port can be confused with a destination service port. A single failed login also does not automatically indicate brute-force activity.
That is why I separate observed evidence from AI-generated hypotheses.
One of the most interesting experiments involved an untrusted SSH log message.
I tested synthetic log content containing text designed to manipulate the model into treating failed authentication as successful authentication.
In a documented retest, the model preserved the failed-login finding.
An earlier test also exposed an unsafe recommendation to block an IP address. I introduced conservative recommendation filtering and regression tests to help keep responses within the lab's read-only investigation scope.
They do not demonstrate complete resistance to prompt injection or guarantee that every AI-generated recommendation is safe.
Security logs are evidence, not instructions.
I wanted the project to demonstrate more than a working screenshot.
The repository includes 31 mocked and offline Python tests, exercised through GitHub Actions using Python 3.10 and 3.12.
The implementation also includes validation of event identity, persistent processing state, structured model responses, and read-only operational boundaries.
However, automated tests alone do not prove production security or detection accuracy.
The lab still has important limitations: manual execution, no continuous alert monitoring, and network restrictions around the local model service that require further verification before broader deployment.
Three lessons stand out from this project.
First, reliable data retrieval comes before AI analysis. Missing alerts can undermine even a well-written incident report.
Second, local AI can assist security investigations, but its output must be validated. A structured response is not necessarily a correct response.
Third, automation needs clear security boundaries. I prefer a system that helps an analyst understand an event over one that performs potentially harmful actions without approval.
My next areas of work include more realistic alert replay tests, better performance measurements, and stronger local-model network restrictions.
The public repository includes the Python implementation, tests, documentation, and sanitized verification examples.
Original engineering article: Building a Local AI SOC Lab with Wazuh and Qwen
I'm interested in how other engineers approach local AI for security operations.
Would you trust a local LLM to prepare incident triage reports if every recommendation required human approval?
Editorial disclosure: This DEV.to adaptation was prepared with AI writing assistance using my original engineering article and documented project results as source material.