Listen to this Post
Introduction:
The emergence of AI-powered Security Operations Centers (SOC) promises to revolutionize threat detection and response, but the reality is far messier than vendor marketing suggests. Current implementations focus on auto alert triage, investigation, detection engineering, and response—yet foundational issues like LLM hallucinations, exorbitant costs, and the inability to detect novel threats from raw telemetry remain unresolved. This article dissects the technical capabilities, limitations, and practical deployment strategies for AI SOC, offering actionable commands and configurations for security engineers.
Learning Objectives:
- Understand the core components of AI SOC and their trade-offs (cost, accuracy, accountability).
- Implement local anomaly detection models and LLM-based triage using open-source tools.
- Apply fine-tuning and grounding techniques to reduce hallucinations in security automation.
You Should Know:
- The Three Pillars of Practical AI SOC: Data, Ontology, and Agentic Pipelines
The comment from Vladimir Potapov highlights that normalized data, a high‑quality cybersecurity ontology, and flexible AI model libraries (LangChain, Scikit‑learn) form the true foundation of AI SOC. Without these, LLMs operate on noisy, unstructured logs and produce unreliable output.
Step‑by‑step guide to building a local data normalization pipeline:
First, ingest raw logs (e.g., Sysmon, Windows Event Logs, Zeek) into a structured format. Use `jq` and `gron` on Linux to flatten JSON logs:
Flatten Zeek DNS logs for easier processing
cat dns.log | jq -c '{ts, uid, query, qtype, answers}' > normalized_dns.json
Convert Windows EVTX to JSON (using evtx_dump from python-evtx)
evtx_dump Security.evtx | jq -c '{EventID, TimeCreated, Computer, EventData}'
On Windows PowerShell, extract specific security event IDs:
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624,4625} | Select-Object TimeCreated, @{Name='Account';Expression={$_.Properties[bash].Value}} | Export-Csv -Path logins.csv
Next, build a simple cybersecurity ontology using a graph database like Neo4j. Populate it with MITRE ATT&CK techniques:
CREATE (t:Technique {id: 'T1078', name: 'Valid Accounts', tactic: 'Defense Evasion'})
CREATE (d:Detection {rule: 'Anomalous login time', confidence: 0.85})
CREATE (t)-[:DETECTED_BY]->(d)
Finally, orchestrate an agent pipeline with LangChain (Python):
from langchain.agents import create_react_agent
from langchain.tools import Tool
from langchain_community.llms import Ollama
Load local LLM (e.g., Mistral)
llm = Ollama(model="mistral:7b")
Define a tool to query normalized logs
def query_logs(query: str) -> str:
Use pandas to filter a CSV of normalized events
import pandas as pd
df = pd.read_csv("normalized_events.csv")
result = df[df['message'].str.contains(query, case=False)]
return result.to_string()
tools = [Tool(name="LogQuery", func=query_logs, description="Search logs for pattern")]
agent = create_react_agent(llm, tools, prompt_template)
This setup keeps data on‑premises, avoids per‑alert cloud costs, and grounds the LLM with deterministic queries.
2. Auto Alert Triage: Costs, Hallucinations, and Accountability
Joshua Neil notes that auto triage saves time but suffers from high cost (enterprise MSSPs find ingestion‑based pricing unsustainable) and hallucinations. Fine‑tuning an adapter (LoRA) and constraining the LLM with structured context are practical mitigations.
Step‑by‑step guide to reducing hallucinations in alert triage:
- Collect a labeled dataset of SIEM alerts with true/false positive labels (e.g., 1000 examples). Export from Splunk/ELK:
Using ELK's search API
curl -X GET "localhost:9200/siem_alerts/_search?size=1000" -H 'Content-Type: application/json' -d'
{
"query": {"match_all": {}},
"_source": ["alert_name", "source_ip", "dest_ip", "label"]
}' > labeled_alerts.json
- Fine‑tune a small LLM with LoRA using Hugging Face PEFT. This trains on your specific alert patterns without full model retraining.
from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import LoraConfig, get_peft_model
model = AutoModelForCausalLM.from_pretrained("microsoft/phi-2")
tokenizer = AutoTokenizer.from_pretrained("microsoft/phi-2")
lora_config = LoraConfig(r=8, lora_alpha=32, target_modules=["q_proj", "v_proj"])
model = get_peft_model(model, lora_config)
Train on prompt-completion pairs: "Alert: Failed login spike\nIs this malicious? ..." -> "True positive, investigate source IP"
- Constrain output via system design – instead of asking the LLM to decide, have it extract evidence and feed a deterministic rule engine.
def triage_alert(alert_dict):
prompt = f"""Extract fields from this alert: {alert_dict}
Return JSON: {{"src_ip": "...", "event_count": int, "anomaly_score": float}}"""
structured = llm.invoke(prompt)
Deterministic logic on structured output
if json.loads(structured)['event_count'] > 100 and alert_dict['time'] between '00:00-04:00':
return "Escalate - likely brute force"
return "Informational"
This hybrid approach eliminates the LLM’s ability to hallucinate a final verdict while leveraging its extraction capability.
- Anomaly Detection: Why LLMs Fail (and What Actually Works)
The core debate: can LLMs find novel threats from raw telemetry? Joshua Neil argues no—use purpose‑built models (UEBA, statistical outlier detection). Logan Carmody counters that a well‑harnessed LLM with instructions like “investigate anomalous AWS secrets access” works well. The compromise: use LLMs for guided analysis of pre‑filtered anomalies, not for raw detection.
Step‑by‑step guide to hybrid anomaly detection (Isolation Forest + LLM investigation):
- Collect raw telemetry (e.g., process creation events from Sysmon Event ID 1 on Windows). Export to CSV:
Windows: Get Sysmon process events
Get-WinEvent -FilterHashtable @{ProviderName="Microsoft-Windows-Sysmon"; ID=1} | ForEach-Object {
$xml = [bash]$_.ToXml()
$eventData = $xml.Event.EventData.Data
$props = @{}
for ($i=0; $i -lt $eventData.Count; $i++) { $props[$eventData[$i].Name] = $eventData[$i].'text' }
[bash]$props
} | Export-Csv processes.csv
- Train an Isolation Forest on numeric features (process frequency, entropy, parent‑child relationships). Use Python:
from sklearn.ensemble import IsolationForest
import pandas as pd
df = pd.read_csv("processes.csv")
features = df[['command_line_length', 'parent_pid_count', 'rare_binary']]
model = IsolationForest(contamination=0.01, random_state=42)
df['anomaly'] = model.fit_predict(features) -1 = outlier
anomalies = df[df['anomaly'] == -1]
- Send only the top‑k anomalies (e.g., 10 per hour) to an LLM agent for investigation, avoiding token burn and rabbit holes.
investigation_prompt = f"""Investigate these anomalous processes:
{anomalies[['timestamp', 'process_name', 'command_line']].head(10).to_markdown()}
For each, explain if it's benign‑but‑rare (e.g., backup script) or potentially malicious. Provide MITRE TTP."""
investigation = llm.invoke(investigation_prompt)
print(investigation)
This architecture scales to large environments (Isolation Forest runs in O(n) time) and only invokes expensive LLMs on suspicious outliers.
- Auto Response and SOAR Integration: The 5‑Nines Problem
Auto‑response (isolating endpoints, disabling accounts) requires near‑perfect accuracy. Joshua Neil notes that hardly any detection achieves the 99.999% needed. The solution is human‑in‑the‑loop (HITL) automation: AI proposes responses, analyst approves or denies.
Step‑by‑step guide to building a HITL auto‑response playbook (using TheHive and Cortex):
- Define a playbook in YAML (e.g., for suspected ransomware):
playbook: ransomware_containment steps: - condition: "alert.severity == 'CRITICAL' and file_extension in ['.encrypt', '.lock']" action: "propose_host_isolation" require_approval: true - condition: "approved == true" action: "execute_ansible_playbook isolate_host.yml" - condition: "approved == false" action: "add_comment: Analyst overridden - manual investigation"
- Implement approval loop via a ticket system (TheHive API):
Create alert in TheHive (curl command)
curl -X POST "http://thehive:9000/api/alert" -H "Authorization: Bearer $API_KEY" -H "Content-Type: application/json" -d '{
"title": "Potential ransomware - isolate host?",
"type": "external",
"source": "AI_SOC",
"description": "Anomalous file encryption pattern on host WEB01",
"severity": 3,
"customFields": {"proposed_action": "isolate_host"}
}'
- On approval, trigger a secure isolation script (Linux for network‑based isolation):
!/bin/bash Block host via iptables (isolate from all but management VLAN) HOST_IP=$1 iptables -I FORWARD -s $HOST_IP -j DROP iptables -I INPUT -s $HOST_IP -j DROP Or use API to disable switch port (Cisco example) ssh switch01 "configure terminal; interface gigabitEthernet 0/12; shutdown"
On Windows, use `New-NetFirewallRule` to block all outbound traffic from an isolated IP:
New-NetFirewallRule -DisplayName "Isolate compromised host" -Direction Outbound -RemoteAddress $HOST_IP -Action Block
This HITL approach maintains accountability while accelerating response.
- Practical SOC Automation with Local LLMs (Avoiding Third‑Party Telemetry Leaks)
Asif Safdary points out that sending sensitive security telemetry to third‑party LLM clouds is a contradiction. Running local models (e.g., Llama 3, Mistral) via Ollama or vLLM keeps data on‑prem and eliminates per‑alert pricing.
Step‑by‑step guide to deploying a local LLM for alert enrichment:
- Install Ollama on a Linux server with GPU:
curl -fsSL https://ollama.com/install.sh | sh ollama pull llama3.2:3b-instruct-fp16 Small, fast model for low‑latency triage
2. Create a system prompt for SOC analysts:
ollama run llama3.2:3b-instruct-fp16 --system "You are a security analyst. Given an alert, output a JSON with: risk_score (1-10), mitre_ttp, and recommended_action. Do not hallucinate facts beyond the alert."
Then pipe an alert
echo '{"alert": "Multiple failed logins from 203.0.113.45 to 10 admin accounts"}' | ollama run llama3.2:3b-instruct-fp16
- Integrate with SIEM via a Python webhook (e.g., Splunk alert action):
from fastapi import FastAPI, Request
import ollama
app = FastAPI()
@app.post("/enrich")
async def enrich_alert(request: Request):
alert = await request.json()
response = ollama.chat(model='llama3.2:3b-instruct-fp16', messages=[
{"role": "system", "content": "Output only JSON"},
{"role": "user", "content": f"Alert: {alert}"}
])
return response['message']['content']
Deploy behind a reverse proxy (nginx) with mutual TLS to ensure only your SIEM can connect.
6. Fine‑Tuning and Continuous Learning from Analyst Feedback
Gene Kazimiarovich argues that hallucinations can be reduced via fine‑tuning adapters and system design, not eliminated. The accountability plane (who fixes the mistake) remains the real issue. Establish a feedback loop where analysts correct AI outputs, then use those corrections to update a LoRA adapter daily.
Step‑by‑step guide to feedback‑driven fine‑tuning:
- Log every AI recommendation and analyst override to a database (PostgreSQL):
CREATE TABLE feedback ( id SERIAL PRIMARY KEY, alert_id TEXT, ai_verdict TEXT, analyst_verdict TEXT, corrected_at TIMESTAMP );
- Periodically convert corrections into training data (prompt‑response pairs for correct classifications). Use a script:
cursor.execute("SELECT alert_id, ai_verdict, analyst_verdict FROM feedback WHERE analyst_verdict != ai_verdict")
for row in cursor.fetchall():
prompt = f"Alert {row[bash]}: classify as malicious or benign\nAI said: {row[bash]}"
response = row[bash]
Append to training.jsonl
- Fine‑tune the adapter weekly using QLoRA to avoid catastrophic forgetting. This reduces hallucination rate on your specific environment over time.
Using axolotl for fine‑tuning pip install axolotl accelerate launch -m axolotl.cli.train config.yml
What Undercode Say:
- Don’t replace anomaly detection with LLMs – use statistical models (Isolation Forest, PCA) for raw telemetry, then LLMs for contextual investigation of outliers. This balances cost, accuracy, and explainability.
- Hallucination mitigation is a system design problem, not a model problem – ground LLMs with deterministic tools (log queries, API calls) and constrain output schemas. Combine fine‑tuning with human‑in‑the‑loop approval for critical actions.
The AI SOC gold rush risks drowning teams in expensive, hallucinating chatbots that cannot detect what they’ve never seen. Winners will adopt hybrid architectures: cheap ML for anomaly scoring, local LLMs for natural language investigation, and rigorous accountability logging. The telemetry gap—finding threats your current rules miss—remains unsolved by foundation models alone. Invest in behavioral baselining and graph‑based context (e.g., using Neo4j to map process trees) before layering on AI.
Prediction:
By 2027, AI SOC products will split into two distinct markets: low‑cost, on‑premise “triage assistants” using small local models (7B parameters) for alert prioritization, and high‑end “detection surfaces” that combine UEBA with graph neural networks for novel threat discovery. The term “AI SOC” will become a commodity label, with competitive differentiation hinging on ontology quality and feedback loop infrastructure—not on which frontier LLM vendor is used. Startups that ignore on‑prem deployment and per‑alert pricing models will fail in the enterprise segment, while MSSPs will build their own internal LLM pipelines to avoid vendor lock‑in. Most importantly, regulators will begin requiring auditable accountability planes for automated security actions, mandating that every AI‑initiated response be traceable to a human approver or a formally verified deterministic rule.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Josh Neil – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
