AI incident analysis cu LLM local: pattern de triaj de la 30 minute la 30 secunde

TL;DR

• Triajul manual al unei alerte SOC durează tipic 15-45 minute (citit log-uri, corelație cu incidente similare, evaluare severitate, scrie sumar).
• Pattern-ul AI incident analysis automatizează această fază: alertă → context din DB istorică → narativ AI → next-action propus → operator validează.
• Cu un LLM open-source de clasă 30-70B parametri rulat local (GPU enterprise), triajul ajunge la 30 secunde per alertă.
• Operatorul primește un sumar gata făcut și acceptă/respinge — atenția lui e folosită doar pentru decizia ireversibilă.
• La 1.000+ alerte/zi, pattern-ul reduce alert fatigue și permite SOC mic să acopere parc mare.

Stack-ul SecOps modern (Wazuh + Suricata + Zeek + Falco + observability metrics) generează 1.000-10.000 alerte/zi pentru un parc de 200-500 servere. Fără triaj automatizat, operatorul citește 100-500 alerte semnificative/zi, fiecare cerând 15-45 minute de investigație. Aritmetica nu funcționează — fie supradimensionezi echipa SOC, fie ignori alertele și pierzi atacuri reale.

Acest articol descrie pattern-ul AI incident analysis pe care îl folosim în AEGIS, arhitectura sa, și de ce un LLM local (nu API frontier) e alegerea corectă.

Problema: alert fatigue

Studii publice (Ponemon, IBM Cost of Data Breach) arată că SOC-urile pierd atacuri pentru că analyst-ii sunt copleșiți. Volumul de alerte depășește capacitatea umană de procesare. Reacția tipică:

1. Threshold raise — ridici severity minimum la care reacționezi. Pierzi atacurile sub threshold.
2. Suppress — blochezi reguli noisy. Pierzi atacurile pe care le ignorai.
3. Outsourcing — externalizezi triajul către MSP. Pierzi context business specific.

Niciuna nu e bună. Toate sacrifică sensitivitate sau context.

Soluția corectă: păstrezi sensitivitatea ridicată (toate alertele importante intră) dar automatizezi triajul de prim nivel. Operatorul vede sumarul AI plus alertele crude, nu fiecare alertă în detaliu.

Pattern-ul: 5 etape

┌──────────────────────────────────────────────────────────────────┐
│                   AI INCIDENT ANALYSIS PIPELINE                   │
│                                                                   │
│  1. ALERT       2. CONTEXT      3. RAG          4. LLM            │
│     Suricata,   Aggregator      Similar         Triage:           │
│     Wazuh,      collects        incidents       severity,         │
│     Falco,      logs in time    from history    type,             │
│     Prometheus  window for      DB              recommendation    │
│                 src/dst                                           │
│                                                                   │
│       ▼            ▼               ▼                ▼             │
│       └────────────┴───────────────┴────────────────┘             │
│                                                                   │
│  5. OPERATOR DASHBOARD                                            │
│     - Original alert                                              │
│     - AI narrative                                                │
│     - Recommended action (block, isolate, ignore, escalate)       │
│     - Operator acts: approve / modify / reject                    │
└──────────────────────────────────────────────────────────────────┘

Etapa 1: alertă

Sursa primară. Suricata emite alertă pe match signature. Wazuh emite alertă pe regulă HIDS escaladată. Prometheus alerta pe metric anomaly. Falco alertă pe runtime container event.

Toate alertele intră în Alertmanager (sau echivalent), care le routează către pipeline-ul AI.

Format standard: JSON cu fields obligatorii — timestamp, source (suricata/wazuh/falco/prometheus), severity, host, src_ip, dst_ip, description, raw_event.

Etapa 2: context aggregator

Un FastAPI primește alerta și agregă context din ultimele N minute (de obicei 30-60 minute) pentru hosts și IP-uri implicate:

• Toate log-urile syslog de pe host-ul țintă în fereastra timpului.
• Toate alertele Suricata/Zeek pentru IP-ul atacator în ultimele 24h.
• Toate evenimentele Wazuh pe host-ul țintă.
• Metric-uri Prometheus relevante (CPU, RAM, network) pe host în fereastră.
• GeoIP, ASN, threat intel match pentru IP-ul atacator.

Output: context structurat, ~5-15 KB JSON.

Etapa 3: RAG cu DB de incidente similare

Aici e diferențiatorul față de un simplu LLM call. Avem o bază de date cu incidente istorice — fiecare cu alerta originală, contextul, narativul AI, decizia operatorului, outcome final (real attack vs false positive).

La o alertă nouă, facem similarity search: găsim 3-5 incidente similare din istoric. “Similar” = embedding similarity pe descrierea alertei + IP/host pattern.

Output: 3-5 incidente similare cu narativul lor și outcome. Acesta intră în prompt-ul LLM ca exemple de few-shot.

DB-ul de incidente se construiește în primele 3-6 luni de operare. Fiecare incident triat de operator se salvează cu decizia finală — pe măsură ce DB crește, calitatea triajului AI crește.

Etapa 4: LLM triage

Prompt-ul către LLM:

Ești analist SOC senior. Primești o alertă SIEM cu context complet și exemple
de incidente similare din istoric. Produci un triaj structurat:

1. SEVERITATE estimată (Low/Medium/High/Critical) cu motivare 1 frază.
2. TIP atac (brute-force / RCE / exfiltration / persistence / scan / other).
3. STARE (active / contained / past).
4. NARATIV (3-5 fraze, explicație pentru operator).
5. RECOMANDARE (block IP / isolate host / ignore / escalate / investigate).

ALERTĂ:
{alerta_json}

CONTEXT (ultimele 60 min):
{context_json}

INCIDENTE SIMILARE:
{similar_incidents}

LLM-ul produce output structurat (JSON) în 2-5 secunde.

Modelul folosit. Open-source modern de clasă 30-70B parametri (familia Qwen3, Llama 3.x sau echivalente), fine-tuned pe corpus intern de incidente. Rulează pe un GPU enterprise (A100/H100 sau equivalent open). Latență: 2-5 secunde end-to-end.

De ce nu API frontier. Două motive: confidențialitatea log-urilor (vezi articolul SIEM on-premise cu LLM local) și costul (10K alerte/zi × 5K tokens/alert = 50M tokens/zi, prohibit pentru API frontier).

Etapa 5: operator dashboard

Pe dashboard apare card cu:

• Alerta originală (raw).
• Narativul AI (citibil în 30 secunde).
• Recomandarea AI cu butoane de acțiune.
• Linkuri către incidentele similare din istoric.
• Buton “feedback” — operatorul marchează triajul ca corect/incorect (alimentează training-ul ulterior).

Operatorul citește narativul, validează cu alerta originală, ia decizia. Pentru ~70% din alerte (cele clare), acceptă recomandarea AI direct. Pentru 25% modifică (severity diferit, action diferit). Pentru 5% respinge complet (fals pozitiv pe care AI-ul nu l-a prins).

Calitatea triajului în producție

În producția curentă (3 luni de operare după faza de pilot):

• Alerte/zi: ~3.500 inițiale → ~800 după filtrare automată în Graylog → AI triage.
• Latență triaj AI: 3-7 secunde mediană (cu p95 la 12 secunde).
• Acceptance rate: 73% recomandări AI acceptate fără modificare.
• Modificare: 22% recomandări modificate (de obicei severity sau detail).
• Reject: 5% recomandări respinse total.
• False negative: 2 cazuri în 3 luni unde AI a marcat “Low” pentru ceva care era real attack. Detectat retrospectiv prin alte signale.

Comparat cu triaj manual (estimare baseline):

• Triaj manual: 15-30 minute mediană per alertă semnificativă.
• Triaj AI + validare operator: 30-60 secunde mediană.
• Throughput operator: de la ~30 alerte/zi (manual) la ~300 alerte/zi (AI-assisted).

Pe parc 200 servere cu 800 alerte/zi semnificative, asta e diferența între nevoia de 3 SOC analysts și 1 SOC analyst.

Capcanele

Hallucination AI. LLM-urile pot inventa detalii. Mitigare: prompt cere doar fields structurate, validare schema la output, prezentare alertei originale ÎN PARALEL cu narativul (operatorul vede ambele).

Bias în DB de incidente. Dacă în primele luni operatorul a triat greșit anumite tipuri, AI învață greșelile. Mitigare: revizuire trimestrială a DB-ului, etichetare manuală a cazurilor edge.

Drift de calitate. Atacurile evoluează. Pattern-uri vechi nu mai apar, pattern-uri noi apar. Mitigare: re-training cu date proaspete trimestrial, plus regulă de safety — alertele cu nicio similaritate la istoric trec automat la operator fără pre-triaj AI.

Infrastructură GPU. GPU enterprise costă. Mitigare: un singur GPU servește 1000-5000 inferențe/oră — capacitate suficientă pentru parc 500-1000 servere.

Interpretabilitate. “De ce a zis AI că e Critical?” — operatorul are nevoie să vadă raționamentul. Mitigare: prompt cere explicit “motivare 1 frază” pentru fiecare câmp, plus linkuri la incidentele similare folosite ca context.

Integrare cu Wazuh Active Response

Pattern-ul AI triage e complementar cu Wazuh Active Response. AR auto-acționează pe regulile clare (SSH brute, signature AV match) — acolo nu are sens să aștepți LLM. AI triage adaugă valoare pe alertele ambigue, unde decizia cere context și raționament.

Schema combinată:

• Alerte clare cu acțiune evidentă → AR direct, plus AI face post-triaj pentru audit.
• Alerte ambigue → AI triage primary, operatorul validează, apoi acțiune (manuală sau AR-trigger).
• Alerte fără pattern în istoric → operatorul direct, fără pre-triaj.

Articole conexe

• SIEM on-premise cu LLM local: AI incident analysis fără să spargi confidențialitatea
• Graylog vs Splunk pentru SMB de 50-500 servere: TCO 3 ani și capcanele de scaling
• TCO SIEM SaaS vs on-premise: 200 servere și 10k events/sec, cifre pe 3 ani
• Observability of AI agents: ce trebuie să monitorizezi în producție
• Pillar AEGIS — SIEM on-premise cu AI local

Pași următori

Implementarea pattern-ului în stack AEGIS cere 2-3 luni: deployment GPU + LLM, integrare cu Alertmanager, build context aggregator, primele 3 luni de DB de incidente, fine-tuning. Vedeți AEGIS pentru roadmap-ul complet sau contact pentru o sesiune tehnică.

Articole conexe: SIEM on-premise cu LLM local · Wazuh Active Response patterns · Suricata + Zeek coexistence · Propose-then-act Iris.

Referințe

• NIST SP 800-92 — Guide to Computer Security Log Management
• MITRE ATT&CK Framework
• Wazuh — Open Source XDR
• Suricata documentation
• OWASP — Logging Cheat Sheet