Using Small Language Models to Detect Cyber Attacks from Wazuh Logs and Firewall Syslog

Security operations centers drown in alerts. A mid-sized enterprise running Wazuh across a few hundred endpoints, plus a FortiGate or similar firewall forwarding syslog, can easily generate tens of thousands of events per day. Traditional rule-based correlation catches known patterns, but it struggles with the long tail: alert bursts that are technically distinct but semantically related, low-and-slow reconnaissance, or context that only a human analyst would recognize as suspicious.

This is where a small language model (SLM) — not a massive frontier model, but a compact 7B–14B parameter model running on-premises — earns its place in the pipeline. It doesn’t replace Wazuh’s detection engine or your SIEM correlation rules. It sits downstream of them, turning structured alert noise into analyst-ready reasoning.

Why an SLM, not an LLM

For SOC workloads, three constraints usually rule out large hosted models:

• Data residency. Enterprise clients in regulated sectors rarely allow raw security logs to leave their network, which rules out most API-based frontier models.
• Latency and cost at volume. Scoring thousands of alert clusters a day needs a model that’s cheap and fast per call, not one billed per token at frontier rates.
• The task doesn’t need frontier reasoning. Classifying an alert burst against MITRE ATT&CK techniques, or writing a two-sentence incident summary, is well within reach of a well-prompted 7B–14B model.

Models like Llama 3.1 8B, Qwen2.5 14B, or Phi-4, served locally through vLLM or Ollama, hit the right balance: good enough instruction-following for structured JSON output, small enough to run on a single GPU inside the client’s own environment.

Where the SLM sits in the pipeline

The mistake to avoid is feeding raw logs directly into the model. Wazuh and your firewall already do normalization — use that. The SLM’s job starts after aggregation, not before it.

flowchart TD
    A["Wazuh agents + FortiGate syslog"] --> B["Wazuh manager: rule matching & normalization"]
    B --> C["OpenSearch: alert aggregation by source IP / time window"]
    C --> D["SLM scoring service: classify, summarize, map to MITRE ATT&CK"]
    D --> E["DFIR-IRIS: enriched case creation"]
    E --> F["Shuffle SOAR: branch on SLM verdict"]
    F --> G["PagerDuty: human analyst escalation"]

Wazuh alerts are already structured JSON — rule ID, severity level, agent, source and destination IPs, and the raw log line. Aggregate correlated alerts into short windows (say, five minutes, grouped by source IP or user) before they ever reach the model. This keeps the SLM reasoning over compact event sequences instead of parsing firehose text, which both lowers cost and improves accuracy.

What the SLM is actually good at

Rule engines are precise but brittle. They’re excellent at "this exact log pattern occurred," and weak at "this sequence of otherwise-unremarkable events looks like an attack in progress." That gap is where an SLM adds value:

• Incident summarization. Turning a cluster of twelve related Wazuh alerts into a two-sentence plain-language summary an on-call analyst can read in five seconds, instead of scrolling through raw logs.
• Pattern reasoning across log sources. Correlating a burst of FortiGate connection denials with a subsequent run of Wazuh authentication failures on the same source IP, and describing why that combination resembles password spraying or credential stuffing — reasoning that static correlation rules often miss unless someone wrote a rule for that exact combination in advance.
• False-positive suppression. Scoring alerts against short embedded context (asset criticality, known maintenance windows, expected admin behavior) to cut noise before a case is even opened in DFIR-IRIS.

Structured output, not free text

The model should never hand back a paragraph for a SOAR platform to parse with regex. Prompt it to return strict JSON:

{
  "severity": "high",
  "mitre_technique": "T1110.003 - Password Spraying",
  "summary": "17 failed logins across 4 accounts from a single external IP within 6 minutes, followed by one successful login.",
  "recommended_action": "disable_account_and_escalate",
  "confidence": 0.82
}

Shuffle can then branch directly on severity and recommended_action fields, routing high-confidence, high-severity cases straight to PagerDuty while lower-confidence ones queue for analyst review.

Guardrails matter more than accuracy

The single most important design decision is what the model is not allowed to do. An SLM in a SOC pipeline should be advisory only — it summarizes, classifies, and recommends, but it never auto-closes a case or auto-remediates a system. Human review stays in the loop for anything above a defined severity threshold. This isn’t just caution for its own sake; it’s the difference between a defensible SOC process and one that can’t answer for a false negative during a client audit.

Getting started without labeled data

Most organizations don’t have a clean dataset of "alert cluster → correct verdict" pairs to fine-tune on, and that’s fine to start. Strong few-shot prompting — a handful of example alert clusters with their correct MITRE mapping and severity, embedded directly in the system prompt alongside your organization’s specific rule descriptions — gets a 7B–14B model to reasonable accuracy immediately. Fine-tuning becomes worthwhile once you’ve accumulated a few hundred real, analyst-verified incidents to train on.

The result is a SOC pipeline where Wazuh and your firewall still do what they’re best at — fast, deterministic detection — while the SLM handles the messier, more contextual layer of reasoning that used to require a tired analyst squinting at a dashboard at 2 a.m.