Building a Local AI SOC Lab with Wazuh and Qwen: Lessons from a Real Implementation

Vitalii Balint — Sat, 24 Oct 2026 04:02:35 +0000

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.

1. My Lab Architecture

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 main components are:

Wazuh Agent: collects security events from an Ubuntu endpoint.
Wazuh Manager and OpenSearch Indexer: process and store security alerts.
Python SOC Assistant: retrieves alerts and prepares them for analysis.
SQLite: tracks processed events and stores generated reports.
LM Studio + Qwen 3.5 4B Instruct: generates structured incident analysis proposals.
Human analyst: reviews findings and determines the next steps.

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.

2. The First Problem: Missing Alerts

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.

In one documented integration test:

152 matching alerts were reported by OpenSearch.

152 alerts were successfully retrieved.

152 unique event IDs were verified.

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.

3. Why I Added SQLite

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.

4. Connecting a Local Qwen Model

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.

Qwen proposed:

Disposition: SUSPICIOUS

Severity: LOW

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.

5. Prompt Injection in Security Logs

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.

These were limited experiments.

They do not demonstrate complete resistance to prompt injection or guarantee that every AI-generated recommendation is safe.

Security logs are evidence, not instructions.

Human review remains essential.

6. Testing and Verification

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.

7. What I Learned

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.

Project Resources

The public repository includes the Python implementation, tests, documentation, and sanitized verification examples.

GitHub: AI-Powered SOC Lab

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.

DEV Community: Vitalii Balint