Cos’è un SOC e come funziona. Davvero.

Massimo Di Bernardo

Sono anni che giro a parlare di SOC, e sempre più spesso mi accorgo che in giro c’è parecchia confusione su cosa sia e come funzioni veramente. Un po’ è colpa del marketing, che ha trasformato tre lettere in una concetto buono per vendere qualsiasi cosa. Un po’ è perché le persone che un SOC lo hanno costruito o gestito davvero sono meno di quanto sembri.

Provo a spiegarlo in modo semplice, senza sconti tecnici ma senza fuffa.

Partiamo dalla base

Un SOC, Security Operations Center, è un team di persone che controlla costantemente tutto quello che accade in un’azienda e che può essere rilevante per la sicurezza informatica.

Come fa a farlo? Guardando i log.

Ogni dispositivo informatico (client, server, apparati di rete, applicazioni cloud) genera log. E i sistemi che si occupano di proteggere l’azienda ne generano di ancora più significativi. Il firewall registra ogni attacco che riceve e ogni connessione che blocca. L’EDR, che poi è molto più di un semplice antivirus (monitora processi, comportamenti e permette di reagire attivamente, non solo di bloccare), alza una bandierina ogni volta che rileva qualcosa di sospetto. I sistemi di gestione delle identità, come Active Directory o Microsoft 365, tracciano ogni login, ogni cambio password, ogni accesso anomalo.

Ogni giorno questi sistemi generano una montagna di log. E nel 99% dei casi nessuno li legge.

Solo a immaginare di avere qualcuno che sta lì tutto il giorno a leggerli, si capisce quanto valore potremmo estrarre. Potremmo prevenire attacchi prima che arrivino, o fermarli mentre sono in corso.

Il problema è la scala.

Il problema di scala

Anche in una piccola o media azienda parliamo di migliaia di eventi al minuto, distribuiti su decine di sistemi diversi. In un’azienda enterprise si arriva facilmente a centinaia di migliaia al minuto.

Di quante persone avremmo bisogno per leggerli tutti? E soprattutto: 24 ore su 24, 7 giorni su 7, festivi inclusi?

Qui ci viene incontro la tecnologia.

Il SIEM, il database “intelligente” della cybersecurity

Immaginiamo di poter raccogliere tutti questi log in un unico database centralizzato. Di renderli uniformi e leggibili su interfacce pensate per gli analisti. Di filtrare i log meno rilevanti. Di aggregare gli eventi simili. Di generare allarmi solo per ciò che conta davvero, in base al rischio.

Questo è un SIEM (Security Information and Event Management). Il cervello che raccoglie, normalizza, correla e prioritizza gli eventi di sicurezza.

Da solo, però, il SIEM non basta. Serve qualcuno davanti.

Le persone: L1, L2, L3

Mettiamo un team di analisti davanti al SIEM, H24. Il loro lavoro è guardare gli eventi più importanti, capire quali approfondire, quali segnalare, e quando scoprono un attacco reagire: bloccare porte sul firewall, isolare sistemi sotto attacco, disabilitare utenze compromesse.

Questa è la versione base di un SOC. E funziona su tre livelli.

Livello 1, Triage. I nuovi arrivati. Guardano gli eventi in arrivo, fanno le prime indagini, filtrano i falsi positivi ed eseguono le reazioni più standardizzate. Lavorano a ritmo alto, seguendo procedure precise. L’obiettivo è non far passare nulla di rilevante e non intasare i livelli superiori con rumore.

Livello 2, Investigation. Analisti più esperti. Quando L1 trova qualcosa che non riesce a chiarire, sale al secondo livello. Qui si scava: si ricostruisce la catena degli eventi, si correlano log da fonti diverse, si valuta l’impatto reale. Serve esperienza, per capire ad esempio se un accesso anomalo è un dipendente in trasferta o un attaccante che sta usando credenziali rubate.

Livello 3, Incident Response e Threat Hunting. Il team più senior. Interviene sugli incidenti gravi (ransomware in corso, compromissioni profonde, APT). E quando non ha emergenze da gestire, fa threat hunting, cioè la caccia proattiva agli attaccanti che sono già dentro senza essere stati rilevati. Ci arriviamo tra poco.

Tutti e tre i livelli lavorano seguendo dei playbook, processi scritti e disegnati in anticipo che definiscono, per ogni scenario, cosa fare, in che ordine e con quali strumenti. Senza playbook, anche i migliori analisti perdono minuti preziosi nel momento sbagliato.

Il SOAR, automatizzare l’ovvio

Tutto questo però genera un carico enorme, difficilmente scalabile, costoso.

E se i playbook potessimo automatizzarli, almeno in parte?

Se quando l’EDR ci dice che un PC è appena stato infettato, uno script lo isolasse automaticamente dalla rete? Se quando un utente si logga in modo geograficamente impossibile, prima dalla Cina e dieci minuti dopo dall’Italia, il suo account venisse disabilitato all’istante?

Questo è un SOAR (Security Orchestration, Automation and Response). Prende gli eventi del SIEM e, tramite playbook automatizzati, “orchestra” gran parte di quello che un essere umano farebbe manualmente.

SIEM + SOAR + L1/L2/L3 l’evoluzione del SOC. Quello che oggi molti MSSP offrono come servizio.

Il problema (enorme) del SOC tradizionale

E qui arriva la parte scomoda.

La fase finale di un attacco ransomware, cioè la cifratura vera e propria dei sistemi, si esegue in minuti. Un SOC tradizionale, per quanto efficiente, ha tempi di reazione di ore. A volte decine di minuti, nel migliore dei casi.

Il risultato? Nella mia esperienza di chi un SOC lo gestisce tutti i giorni, la maggior parte dei SOC oggi non ferma gli attacchi. Li registra. Contiene i danni, ricostruisce la catena, aiuta nella recovery. Raramente ferma l’attacco mentre sta accadendo.

Non è incompetenza. È matematica. Un essere umano non può guardare migliaia di eventi al minuto, e la latenza tra “alert” e “azione” è strutturalmente troppo alta.

E allora come ci si difende?

Il threat hunting: cercare ciò che non è stato visto

Qui entra l’attività più sofisticata, e più sottovalutata, di un SOC: il threat hunting.

Il presupposto è scomodo ma realistico: “assumed breach”. Dai per scontato di essere già stato compromesso e vai a cercare le tracce dell’attaccante.

Per capire perché questa attività è così critica, faccio un esempio.

Scenario 1. Immagina che l’attaccante sia il responsabile IT di un’azienda, che odia il suo datore di lavoro e vuole piazzare un ransomware. Conosce ogni sistema, ha tutte le password, può spegnere firewall e antivirus prima di agire. Sa che nessuno lo sta controllando. A questa persona basterebbero pochi giorni per pianificare e sferrare un attacco devastante.

Scenario 2. Un attaccante esterno entra rubando credenziali tramite phishing. Non sa dove è finito. Non ha privilegi. Non conosce la rete. Non sa dove sono i server critici, né i backup. Non sa nemmeno se l’azienda ha un SOC, o se c’è qualcuno che ogni tanto controlla i log.

È lo scenario 2 la realtà quotidiana. E spiega perché un attaccante, prima di sferrare il colpo vero, resta in rete giorni, settimane, a volte mesi. Deve esplorare, scalare privilegi, individuare i sistemi critici, preparare l’esfiltrazione, sabotare i backup. Secondo il Mandiant M-Trends 2025, la permanenza media globale prima del rilevamento è di 11 giorni, ma negli attacchi più sofisticati (spionaggio industriale, attori statali) può arrivare a mesi.

Il threat hunting serve proprio a stanare l’attaccante in questa fase, prima che colpisca.

Come si fa threat hunting, in pratica

Non è magia. Sono tecniche concrete che lavorano su diversi piani.

Honeypot e honeytoken. Sono esche. Un finto server con un nome invitante (“fileserver-hr”, “backup-dc”), credenziali finte lasciate in un file dimenticato, i cosiddetti canary file (documenti-trappola che non hanno altro scopo se non farsi aprire: se qualcuno li tocca, sai che hai un problema). Un utente legittimo non ha motivo di interagirci. Chi lo fa, con altissima probabilità, è un attaccante in fase di ricognizione.

Monitoraggio dell’esposizione di credenziali. Gli attaccanti comprano e vendono credenziali rubate sul dark web, spesso ore o giorni prima di usarle. Piattaforme di threat intelligence monitorano questi mercati e ci avvisano se compaiono credenziali della nostra azienda. Cambiare la password prima che venga usata è la forma più economica di difesa.

NDR e movimenti laterali. L’NDR (Network Detection and Response) è il gemello di rete dell’EDR. Mentre l’EDR vede cosa succede dentro un endpoint, l’NDR vede cosa si parla tra gli endpoint. È fondamentale perché un attaccante esperto, una volta entrato, disattiva l’EDR, ma non può nascondere il traffico di rete. I movimenti laterali sono proprio le comunicazioni interne con cui l’attaccante si sposta dal primo PC compromesso verso server, domain controller, backup. Usa i protocolli amministrativi interni di Windows, esattamente quelli che ogni IT manager usa per gestire la rete, solo in contesti, orari e quantità che un utente legittimo non userebbe mai. Tracce che un NDR raccoglie e che il threat hunter sa leggere.

Caccia guidata da intelligence. Quando esce un nuovo TTP (Tactic, Technique and Procedure) pubblicato su MITRE ATT&CK, o una campagna attiva nel nostro settore, l’hunter formula un’ipotesi: “se fossi un attaccante che usa questa tecnica, dove lascerei traccia nei miei log?”. E va a verificare.

Analisi delle anomalie. Un utente che all’improvviso scarica 50 volte il volume di dati che muove di solito. Un server che inizia a comunicare con un paese dove non ha mai parlato prima. Una connessione DNS ripetuta ogni 60 secondi verso un dominio mai visto (segnale tipico di un command and control). Tutte cose che sfuggono alle regole statiche, ma che emergono se confronti il comportamento attuale con la baseline.

Ogni caccia che va a segno produce un risultato doppio: l’incidente viene fermato, e nasce una nuova regola di detection. Quello che oggi l’hunter trova a mano, domani il SIEM lo rileva in automatico. È un meccanismo che, nel tempo, alza progressivamente il livello della difesa.

Un SOC vale quanto il contesto in cui opera

C’è un punto che chi vende SOC raramente racconta: un SOC è efficace quanto l’azienda che difende gli permette di esserlo.

Se i log non arrivano perché i sistemi non sono configurati bene, se non c’è un referente reperibile alle 3 del mattino, se non sono chiari i criteri di autorizzazione per spegnere un server in produzione, anche il miglior team del mondo è cieco o paralizzato nei momenti che contano davvero.

Il SOC è metà tecnologia e metà integrazione con l’azienda. Processi definiti, contatti chiari, log completi, responsabilità scritte nero su bianco. Senza questa metà, si compra un servizio che, nel momento del bisogno, scopre di non poter agire.

È un punto che faccio quasi sempre con i clienti: prima di firmare un contratto con qualsiasi fornitore SOC, mettete in ordine i presupposti. Altrimenti state comprando un’assicurazione che, nel momento del sinistro, non può pagare.

L’AI agentica: il vero cambio di passo

Qualche tempo fa qualcuno ha inventato le AI generative. E subito dopo, le AI agentiche, cioè sistemi che non si limitano a rispondere, ma agiscono: eseguono azioni, prendono decisioni, portano a termine compiti complessi.

Applicate a un SOC, cambiano le regole del gioco. Faccio un esempio concreto.

Ore 3:47 del mattino. Un account aziendale si logga da un IP mai visto prima.

In un SOC tradizionale, l’analista L1 del turno di notte ha in coda 40 alert. Impiega tre o quattro minuti per arrivare a questo, verificare l’IP su una piattaforma di reputation, guardare se l’utente ha MFA attivo, controllare se ci sono stati altri login sospetti nella stessa finestra. Se è stanco, se gli altri alert sono più rumorosi, magari ci arriva in dieci minuti.

Un agente AI lo gestisce in otto secondi. Verifica la reputation dell’IP, controlla l’MFA, confronta il login con la baseline di comportamento dell’utente (da dove si logga di solito, a che ora, con quale dispositivo), cerca login correlati da altri account nella stessa finestra temporale, interroga la threat intelligence. A seconda dell’esito chiude il ticket, avvia una remediation automatica, oppure scala a un analista umano con un dossier già pronto.

Non si è distratto. Non era stanco. Non aveva 39 alert davanti. Non aveva pregiudizi sul “solito falso positivo” di quell’utente che si lamenta sempre.

Un SOC agentico non campiona gli eventi: li controlla tutti. Triage, investigation e prima remediation vengono eseguiti in secondi o minuti, non in ore.

Le AI possono sbagliare? Sì, possono. Ma molto meno degli esseri umani. E soprattutto non si stancano alle 3 di notte del sabato, quando un attaccante sa perfettamente che il SOC è scoperto.

Oggi i SOC con un vero team agentico basato su AI di alto livello sono pochissimi. Ma la direzione è chiara. Chi resta sul modello solo umano farà fatica a reggere il passo degli attacchi automatizzati dei prossimi anni.

Quanto costa un SOC

Il costo di un servizio SOC dipende essenzialmente da una cosa: il numero di eventi da gestire.

I modelli commerciali variano (numero di utenti, volume di log giornalieri, numero di sistemi connessi), ma alla fine il driver reale è sempre la quantità di dati da processare, che dipende dalla dimensione dell’azienda e dal numero di sistemi di sicurezza già in campo.

Le AI aiutano a comprimere i costi operativi, ma non sono gratis. Soprattutto quelle evolute (ogni riferimento a certi LLM è puramente casuale). Chi racconta che l’AI azzererà il costo del SOC sta vendendo un’illusione.

Per chiudere

Un SOC non è un prodotto. Non è un software. E non è nemmeno una dashboard con le lucine verdi e rosse.

È persone, processi e tecnologie che lavorano insieme con un unico obiettivo: comprimere il tempo tra “è successo qualcosa” e “lo stiamo fermando”.

In cybersecurity, quel tempo fa la differenza tra un incidente contenuto e un disastro che finisce sui giornali.

Il SOC di domani, quello che davvero riesce a fermare gli attacchi e non solo a registrarli, sarà un sistema ibrido: intelligenza umana per le decisioni complesse e per il contesto, intelligenza artificiale per la velocità e la scala.

Ci stiamo entrando adesso.