Costruire il proprio SOC Wazuh, o installarne uno già costruito

Cosa dovete costruire

Wazuh di serie fornisce un manager, un indexer e un agente. Tutto ciò che sta sopra è il progetto: manager e indexer per singolo cliente, un piano di controllo per il loro provisioning, isolamento dei tenant a livello di database, network policy, la parte idraulica dell'enrollment degli agenti, un workflow di triage e strumenti di upgrade. Ogni pezzo, preso da solo, è affrontabile; integrarli tutti, e mantenerli integrati man mano che arrivano i clienti, è dove finiscono i mesi di ingegneria. Aggiungete un livello di triage AI e diventano vostri anche i prompt, l'orchestrazione degli strumenti verso Wazuh e le vostre fonti di arricchimento, i guardrail perché il modello non chiuda ciò che non deve, i budget di token e un workflow di revisione intorno a tutto questo.

SocTalk consegna quei pezzi già assemblati: un piano di controllo che esegue pile Wazuh per singolo cliente in namespace Kubernetes isolati, con pipeline di triage e coda di revisione incluse. Un imbuto deterministico di dedup, coalescenza e correlazione risolve molti alert prima di qualsiasi chiamata al modello, ogni escalation passa dalla revisione umana senza alcuna modalità di approvazione automatica, e l'LLM lo scegliete voi per ciascun tenant, incluso un Ollama completamente locale. Tutto è Apache 2.0, il chart punta a Kubernetes 1.30+ standard e un'installazione di produzione richiede circa un'ora su un cluster preparato.

Isolamento dei tenant

La multi-tenancy è la decisione di progetto da azzeccare presto, e sulla strada del fai da te tocca a voi dimostrarla. Significa policy di row-level security su ogni tabella legata al tenant, identità del tenant propagata in ogni query e dashboard, network policy e quote di risorse per tenant, e una suite di test che dimostri che le query cross-tenant falliscono davvero. Gli script di provisioning scritti per il terzo cliente devono funzionare ancora per il trentesimo.

SocTalk applica FORCE ROW LEVEL SECURITY su ogni tabella Postgres legata al tenant, con sette test di isolamento che devono obbligatoriamente passare in CI. Ogni cliente riceve un manager e un indexer Wazuh dedicati nel proprio namespace, con Cilium NetworkPolicy, ResourceQuota e segreti di enrollment degli agenti limitati al tenant. La pila è testata fino a ~50 tenant su un cluster a 3 nodi; prevedete circa da 6 a 8 GB di RAM e 1.5 vCPU per tenant persistente.

Onboarding e upgrade

In una pila fatta in casa ogni nuovo cliente è un runbook: tirare su la sua istanza Wazuh, collegare DNS e segreti di enrollment, costruire le sue dashboard e ricondurre tutto agli strumenti centrali che avete scritto. Gli upgrade si moltiplicano allo stesso modo. Gli avanzamenti di versione di Wazuh moltiplicati per il numero di clienti, le migrazioni di schema, la rotazione dei certificati e il ciclo di vita di Kubernetes diventano tempo di ingegneria ricorrente che cresce con ogni tenant.

SocTalk fa l'onboarding dal piano di controllo. Il provisioning esegue nove fasi ordinate con retry idempotente, creando namespace, quote, pila Wazuh ed endpoint di enrollment, e gli agenti si registrano tramite ingress instradato per hostname con segreti limitati al tenant. Il collegamento di DNS e load balancer per tenant resta manuale nella V1, e un profilo 'provided' aggancia un Wazuh che già gestite. Entrambi i chart si aggiornano con helm upgrade e migrazioni di database applicate automaticamente, anche se oggi gli upgrade dell'intera flotta sono un ciclo manuale documentato sui namespace dei tenant; una API di upgrade della flotta è nella roadmap, non ancora rilasciata.

Quanto costa

Le licenze costano zero su entrambe le strade. Wazuh è open source e SocTalk è Apache 2.0, senza divisione community/enterprise e senza funzionalità bloccate. La differenza è dove finisce la spesa. Una costruzione fai da te costa mesi di ingegneria in anticipo, più il tempo continuo per tenerla in piedi, uno scambio ragionevole se la piattaforma è dove volete la vostra squadra. Con SocTalk pagate la vostra infrastruttura e i token LLM, nell'ordine di $9 al giorno per tenant a 30 alert al giorno su una configurazione economica, cifra molto variabile, oppure zero costo per token con un Ollama locale.

Quando costruirlo da soli ha senso

SocTalk presuppone un piano dati Wazuh. Il piano dati di SocTalk oggi è solo Wazuh; altri SIEM sono aggiunte fattibili alla sua superficie di strumenti, ma nessuna è disponibile. Una pratica centrata su Splunk o Elastic è servita meglio dal proprio lavoro di integrazione.

Costruite in proprio anche se la piattaforma SOC è di per sé il vostro elemento di differenziazione. Logica di correlazione personalizzata, un'esperienza analista proprietaria e workflow che i concorrenti non possono copiare sono tutti argomenti a favore del possedere ogni livello, e una piattaforma preconfezionata sarebbe per lo più d'intralcio.

Se siete davvero indecisi, il sorgente è su github.com/soctalk/soctalk sotto Apache 2.0. Leggete le policy RLS, il modello di rete e la pipeline di triage prima di decidere. Nel caso peggiore ne uscite con un'architettura di riferimento funzionante per la vostra costruzione.

Cosa mantenete in entrambi i casi

SocTalk gira sul vostro Kubernetes, da una macchina bare metal fino a EKS, AKS o GKE, anche air-gapped se serve, con la scelta dell'LLM per tenant, inclusa un'opzione completamente locale. Il self-hosting è una costante su entrambe le strade. Mantenete la vostra infrastruttura e i vostri dati, e la relazione con il cliente non passa mai da un fornitore.

È la pila fai da te con l'assemblaggio già fatto, e la licenza fa sì che il tetto sia lo stesso di una costruzione in proprio: tutto quello che sta nel repository è Apache 2.0, non esiste un livello enterprise trattenuto, e se un giorno non condividete la direzione del progetto potete fare un fork e continuare a operare.