Listen to this Post
Introduction:
The Security Information and Event Management (SIEM) market has reached an inflection point. According to industry trackers, 32 vendors now offer both SIEM and AI-powered Security Operations Center (SOC) capabilities, with traditional players like Splunk, Microsoft Sentinel, and Palo Alto Networks Cortex XSIAM all integrating autonomous triage and investigation features. Yet as Filip Stojkovski, Director of SecOps AI Strategy at BlinkOps, points out, “AI SOC meant something different to almost every one of them” – ranging from basic enrichment to full forensic investigation and automated remediation. This fragmentation creates a dangerous gap: while every vendor claims to have AI SOC, the depth, breadth, and real-world effectiveness vary wildly, leaving security teams to decipher marketing hype from operational reality.
Learning Objectives:
- Deploy and configure an AI‑augmented SIEM stack using open‑source tools (Wazuh, Elastic Stack, OpenSearch) with autonomous triage capabilities.
- Implement log ingestion pipelines, correlation rules, and LLM‑powered investigation engines to reduce mean time to respond (MTTR) by 80%.
- Harden cloud environments (AWS, Azure, GCP) and APIs against AI‑driven attacks while integrating SOAR workflows for automated remediation.
You Should Know:
- Understanding the AI SOC Architecture – From Data Ingestion to Autonomous Response
The modern AI SOC is not a single product but a layered architecture that combines traditional SIEM functions with machine learning and large language models (LLMs). Stojkovski’s framework identifies four essential components: a Data Ingestion and Normalization Engine, a Knowledge Graph for contextual awareness, an Investigation Engine combining automations and LLM rules, and a Response layer with remediation actions and feedback loops. This architecture mirrors production‑ready open‑source implementations like the AI‑SOC platform on GitHub, which uses Wazuh Manager for event processing and correlation, OpenSearch for indexing, and Suricata/Zeek for network monitoring.
Step‑by‑Step Guide: Deploying an Open‑Source AI SOC Stack on Linux
This guide sets up a lightweight AI SOC environment using Wazuh, Elasticsearch, and a custom Python investigation agent.
Step 1: Install Wazuh Manager (SIEM Core)
For Debian/Ubuntu curl -s https://packages.wazuh.com/key/GPG-KEY-WAZUH | apt-key add - echo "deb https://packages.wazuh.com/4.x/apt/ stable main" | tee /etc/apt/sources.list.d/wazuh.list apt-get update && apt-get install wazuh-manager -y systemctl start wazuh-manager && systemctl enable wazuh-manager
Step 2: Deploy OpenSearch as the Indexer
Install OpenSearch (replace with your OS version) wget https://artifacts.opensearch.org/releases/bundle/opensearch/2.11.0/opensearch-2.11.0-linux-x64.deb dpkg -i opensearch-2.11.0-linux-x64.deb systemctl start opensearch && systemctl enable opensearch
Step 3: Configure Log Ingestion with Filebeat
Install Filebeat and point to Wazuh indexer curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-8.10.0-amd64.deb dpkg -i filebeat-8.10.0-amd64.deb Edit /etc/filebeat/filebeat.yml to set output.opensearch hosts: ["localhost:9200"] systemctl start filebeat
Step 4: Deploy the AI Investigation Agent (Python + LLM)
Create a script that queries the SIEM, enriches alerts with threat intelligence, and suggests remediation.
import requests
import json
from openai import OpenAI or use local LLM via Ollama
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
def fetch_alerts(siem_url, api_key):
headers = {"Authorization": f"Bearer {api_key}"}
resp = requests.get(f"{siem_url}/alerts?status=open", headers=headers)
return resp.json()
def investigate(alert):
prompt = f"Analyze this SIEM alert and suggest containment steps: {json.dumps(alert)}"
response = client.chat.completions.create(
model="llama2",
messages=[{"role": "user", "content": prompt}]
)
return response.choices[bash].message.content
alerts = fetch_alerts("http://localhost:55000", "your-api-key")
for a in alerts[:5]:
print(f"Alert {a['id']}: {investigate(a)}")
This stack gives you a functional AI SOC with autonomous triage, and you can extend it with custom LLM rules for your specific threat models.
- Log Ingestion and Normalization – The Foundation of AI‑Driven Triage
AI SOCs are only as good as the data they consume. Log normalization – converting disparate formats into a unified schema – is critical for correlation and LLM reasoning. Stojkovski emphasizes that “data ingestion and normalization” is the first pillar of any AI SOC. Without it, even the most advanced AI models produce garbage‑in‑garbage‑out results.
Step‑by‑Step Guide: Ingesting Linux and Windows Logs into Your SIEM
Linux: Forwarding syslog and auditd logs
Configure rsyslog to forward to SIEM echo ". @your-siem-ip:514" >> /etc/rsyslog.conf systemctl restart rsyslog Enable auditd for detailed system call logging auditctl -e 1 auditctl -w /etc/passwd -p wa -k identity_changes ausearch -k identity_changes --format json View in JSON for SIEM ingestion
Windows: Using Winlogbeat to ship Event Logs
Download and install Winlogbeat Invoke-WebRequest -Uri "https://artifacts.elastic.co/downloads/beats/winlogbeat/winlogbeat-8.10.0-windows-x86_64.zip" -OutFile winlogbeat.zip Expand-Archive winlogbeat.zip -DestinationPath C:\ProgramData\winlogbeat Edit winlogbeat.yml to set output.elasticsearch hosts and index name .\winlogbeat.exe -c .\winlogbeat.yml -e
Normalization with Logstash (or OpenSearch Ingestion Pipelines)
logstash.conf – transform Windows Event IDs to MITRE ATT&CK tactics
filter {
if [bash] == 4624 {
mutate { add_field => { "[bash][tactic]" => "Credential Access" } }
}
if [bash] == 4688 {
mutate { add_field => { "[bash][tactic]" => "Execution" } }
}
}
Once normalized, your AI agent can correlate events across sources – for example, linking a failed SSH login (Linux) with a successful logon (Windows) to detect lateral movement.
- Building the Knowledge Graph – Context Is Everything
Stojkovski notes that “context is everything” in an AI SOC. A knowledge graph maps relationships between assets, users, vulnerabilities, and threat actors, enabling the AI to understand that a suspicious PowerShell command on a domain controller is far more critical than the same command on a developer workstation.
Step‑by‑Step Guide: Creating a Lightweight Knowledge Graph with Neo4j
Step 1: Install Neo4j on Ubuntu
wget -O - https://debian.neo4j.com/neotechnology.gpg.key | apt-key add - echo 'deb https://debian.neo4j.com stable latest' | tee /etc/apt/sources.list.d/neo4j.list apt-get update && apt-get install neo4j -y systemctl start neo4j
Step 2: Ingest asset and vulnerability data
// Create nodes for assets
CREATE (dc:Asset {name: "DC01", type: "Domain Controller", criticality: 10})
CREATE (dev:Asset {name: "DEV-WS-23", type: "Workstation", criticality: 3})
// Create relationships
CREATE (dc)-[:HAS_VULNERABILITY]->(vuln:Vulnerability {cve: "CVE-2024-1234", severity: "Critical"})
Step 3: Query the graph for contextual alerting
MATCH (a:Asset)-[:HAS_VULNERABILITY]->(v:Vulnerability {severity: "Critical"})
MATCH (a)<-[:ORIGINATED_FROM]-(alert:Alert)
RETURN alert, a, v
Integrate this graph with your SIEM by using APIs – when an alert fires, the AI agent queries the graph to determine if the affected asset is critical, automatically escalating high‑risk incidents.
- Autonomous Investigation with LLM Rules and Agentic Workflows
The Investigation Engine is where AI truly transforms SOC operations. Instead of analysts manually sifting through alerts, agentic AI “performs foundational investigative tasks with the rigor and expertise of a SOC analyst, but at AI speeds”. Stojkovski describes this as a “combo of automations, LLM rules”. Modern platforms like Rapid7’s Incident Command automate triage with 99.93% accuracy, saving over 200 SOC hours per week.
Step‑by‑Step Guide: Writing LLM‑Powered Investigation Rules
This example uses a local LLM (Ollama) to analyze SSH brute‑force alerts and recommend actions.
Step 1: Install Ollama and pull a model
curl -fsSL https://ollama.com/install.sh | sh ollama pull mistral:7b-instruct
Step 2: Create a Python investigation script that queries the LLM
import requests
import json
from datetime import datetime, timedelta
SIEM_URL = "http://localhost:55000"
LLM_URL = "http://localhost:11434/api/generate"
def get_bruteforce_alerts():
Query Wazuh for failed SSH attempts in last 15 mins
resp = requests.get(f"{SIEM_URL}/alerts?rule.groups=ssh×tamp>={datetime.now()-timedelta(minutes=15)}")
return resp.json()
def llm_analyze(alerts):
prompt = f"""
You are a SOC analyst. Review these SSH brute‑force alerts:
{json.dumps(alerts, indent=2)}
Provide:
1. A severity assessment (Critical/High/Medium/Low)
2. Recommended immediate actions (with Linux commands)
3. Whether this requires human escalation
"""
payload = {"model": "mistral", "prompt": prompt, "stream": False}
resp = requests.post(LLM_URL, json=payload)
return resp.json()["response"]
alerts = get_bruteforce_alerts()
if alerts:
print(llm_analyze(alerts))
Step 3: Automate remediation via SOAR
If the LLM recommends blocking an IP, trigger a firewall rule automatically:
Add to iptables iptables -A INPUT -s 192.168.1.100 -j DROP Or using AWS CLI for cloud environments aws ec2 authorize-security-group-ingress --group-id sg-123456 --protocol tcp --port 22 --cidr 192.168.1.100/32
This closed‑loop feedback model – detect, investigate, remediate – is the hallmark of a mature AI SOC.
- SOAR Integration and Automated Response – From Triage to Containment
A SIEM with AI SOC and SOAR “and all the other bells and whistles is still called a SIEM,” Stojkovski observes. But the addition of automated response actions transforms detection into prevention. The Response layer should include “remediation actions and feedback loop” to continuously improve detection logic.
Step‑by‑Step Guide: Building a SOAR Playbook with TheHive and Cortex
Step 1: Deploy TheHive (case management) and Cortex (automation engine)
Using Docker Compose for quick deployment git clone https://github.com/StrangeBeeCorp/docker-thehive.git cd docker-thehive docker-compose up -d
Step 2: Create a playbook for ransomware detection
When the SIEM detects a ransomware indicator (e.g., mass file encryption events), trigger this playbook:
– Isolate the host using CrowdStrike Falcon or Microsoft Defender API.
– Capture a memory dump for forensics.
– Create a case in TheHive with all relevant alerts.
Step 3: API integration example (Python)
import requests
THEHIVE_URL = "http://localhost:9000"
API_KEY = "your-api-key"
def create_case(alert):
case = {
"title": f"Ransomware detected on {alert['host']}",
"description": f"Alert: {alert['rule']}\nAffected assets: {alert['assets']}",
"severity": 4, Critical
"tags": ["ransomware", "incident-response"]
}
headers = {"Authorization": f"Bearer {API_KEY}", "Content-Type": "application/json"}
resp = requests.post(f"{THEHIVE_URL}/api/case", json=case, headers=headers)
return resp.json()
Step 4: Feedback loop – update SIEM rules based on incident outcomes
After the incident is resolved, use the case data to fine‑tune detection rules:
Example: Add a new Sigma rule for the observed TTP echo "title: Suspicious PowerShell Encoded Command logsource: product: windows service: powershell detection: selection: EventID: 4104 ScriptBlockText|contains: '-EncodedCommand' condition: selection" > /etc/wazuh/rules/local/sigma_powershell.yml
This integration ensures that your AI SOC learns from every incident, reducing false positives over time.
- Cloud Hardening for AI‑Powered SOCs – Securing the Infrastructure
As organizations move to multi‑cloud environments, SIEMs must ingest cloud logs (AWS CloudTrail, Azure Activity Logs, GCP Audit Logs) and harden against AI‑driven attacks like prompt injection or model poisoning. Stojkovski’s framework implicitly requires that the underlying data pipelines be secure and resilient.
Step‑by‑Step Guide: Hardening Cloud Logging and SIEM Access
AWS: Enable comprehensive logging and restrict access
Enable CloudTrail for all regions
aws cloudtrail create-trail --1ame siem-trail --s3-bucket-1ame my-siem-logs --is-multi-region-trail
aws cloudtrail start-logging --1ame siem-trail
Restrict SIEM IAM role to read‑only permissions
{
"Version": "2012-10-17",
"Statement": [
{"Effect": "Allow", "Action": ["cloudtrail:LookupEvents", "logs:DescribeLogGroups"], "Resource": ""}
]
}
Azure: Stream Activity Logs to Event Hub for SIEM ingestion
Create Event Hub and diagnostic setting $eventHub = New-AzEventHub -ResourceGroupName "rg-siem" -1amespaceName "siem-1s" -1ame "siem-eh" Set-AzDiagnosticSetting -ResourceId "/subscriptions/xxx/resourcegroups/rg-siem/providers/microsoft.insights/activitylogs" ` -EventHubName $eventHub.Name -Enabled $true
GCP: Export Audit Logs to Pub/Sub
gcloud logging sinks create siem-sink pubsub.googleapis.com/projects/my-project/topics/siem-topic \ --log-filter='logName:"cloudaudit.googleapis.com"'
Secure the SIEM API endpoints
- Use mutual TLS (mTLS) for agent‑to‑SIEM communication.
- Implement rate limiting to prevent DoS attacks against the AI investigation engine.
- Encrypt all logs at rest and in transit using AES‑256 and TLS 1.3.
- API Security in the AI SOC – Protecting the Intelligence Layer
Modern AI SOCs expose APIs for log ingestion, alert retrieval, and remediation actions. These APIs are prime targets for attackers. Stojkovski’s work with SecOps Unpacked highlights the need for “robust integration and explainability” – but security must extend to the API layer itself.
Step‑by‑Step Guide: Securing Your SIEM APIs
Implement API keys with least‑privilege access
Flask middleware for API key validation
from flask import Flask, request, abort
app = Flask(<strong>name</strong>)
VALID_KEYS = {"readonly": "key1", "admin": "key2"}
@app.before_request
def validate_key():
key = request.headers.get("X-API-Key")
if key not in VALID_KEYS.values():
abort(401)
Optionally scope permissions based on key
Enable audit logging for all API calls
Log every API request to a separate index for forensic analysis
curl -X POST "http://localhost:9200/api-audit/_doc" -H "Content-Type: application/json" -d '{
"timestamp": "'$(date -Iseconds)'",
"user": "[email protected]",
"action": "get_alerts",
"ip": "192.168.1.100"
}'
Rate limit and monitor for abuse
Using NGINX as a reverse proxy:
location /api/ {
limit_req zone=siem_api burst=20 nodelay;
proxy_pass http://siem-backend:55000;
}
Regularly rotate API keys and use short‑lived tokens (JWT with 15‑min expiry)
What Undercode Say:
- Key Takeaway 1: AI SOC is rapidly becoming a commodity feature, but “how good, how broad, how deep is up to you to decide”. Organizations must move beyond vendor checkboxes and rigorously evaluate the actual autonomy, explainability, and integration depth of each platform.
-
Key Takeaway 2: The four‑pillar framework – Data Ingestion, Knowledge Graph, Investigation Engine, and Response – provides a practical litmus test. If a vendor lacks any of these, their “AI SOC” is likely just rebranded automation.
-
Analysis: The fragmentation of AI SOC definitions creates both risk and opportunity. On one hand, security teams may purchase inadequate solutions, expecting full autonomy and getting only basic enrichment. On the other, this heterogeneity allows early adopters to build best‑of‑breed stacks, combining open‑source SIEMs with specialized AI agents. The key is to treat AI SOC as a continuous capability, not a one‑time purchase. Stojkovski’s call for standardization – “maybe one day they get standardized and we all agree” – is both a warning and a roadmap. Until then, SOC leaders must demand transparency, test rigorously, and maintain human oversight for high‑stakes decisions. The commoditization of AI SOC is inevitable, but operational excellence remains a competitive differentiator.
Prediction:
- +1 By 2027, 80% of enterprise SIEM deployments will include some form of AI SOC, but only 20% will achieve autonomous triage beyond 90% accuracy, widening the gap between marketing and reality.
- +1 Open‑source AI SOC stacks (Wazuh + Ollama + TheHive) will gain enterprise traction, reducing vendor lock‑in and enabling custom LLM fine‑tuning for specific threat models.
- -1 The lack of standardization will lead to a “tiered” AI SOC market, where premium vendors offer deep forensics and remediation, while budget options provide only surface‑level summarization, creating a two‑speed security landscape.
- -1 As AI SOCs become commoditized, attackers will shift to adversarial AI techniques – prompt injection, data poisoning, and model evasion – forcing SOCs to invest in AI security posture management (AI‑SPM) alongside traditional SIEM.
- +1 The feedback loop between SIEM and AI agents will mature, enabling continuous detection rule optimization and reducing false positives by 60% within 18 months, directly addressing analyst burnout.
▶️ Related Video (72% Match):
https://www.youtube.com/watch?v=0IgBfGVRYSg
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Filipstojkovski Friday – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
