Punti chiave
- SOC sta per Security Operations Center: la combinazione di persone, processi e tecnologie che monitora, rileva e risponde agli incidenti, idealmente 24 ore su 24.
- Le sue funzioni vanno dal monitoraggio continuo al triage, dall'investigation all'incident response, fino al threat hunting e al reporting.
- I componenti tipici sono analisti su livelli L1, L2 e L3, un SIEM, strumenti di automazione (SOAR), EDR o XDR e threat intelligence.
- Si misura con metriche precise: MTTD (tempo di rilevamento), MTTR (tempo di risposta) e dwell time.
- Può essere interno o gestito: un SOC interno 24/7 richiede circa 6 analisti, un dato che pesa nella scelta.
La risposta breve: un SOC (Security Operations Center) è la combinazione di persone, processi e tecnologie che monitora, rileva, analizza e risponde agli incidenti di sicurezza, idealmente 24 ore su 24, 7 giorni su 7. Non è un prodotto che si compra, è una funzione: il centro operativo che tiene gli occhi aperti sulla sicurezza dell'azienda quando gli altri dormono. Detto in una riga: se il SIEM è lo strumento, il SOC è chi lo usa per accorgersi degli attacchi e reagire.
In questa guida vediamo cos'è un SOC e cosa fa davvero, da quali componenti è fatto, chi ci lavora, con quali metriche si misura, quanto costa tenerlo in casa rispetto ad affidarlo a un partner e in che direzione sta andando con l'arrivo dell'automazione e degli agenti.
Che cos'è un SOC?
SOC è l'acronimo di Security Operations Center, centro operativo per la sicurezza. La definizione più onesta tiene insieme tre elementi, e conta che ci siano tutti e tre.
- Persone: gli analisti che guardano gli allarmi, li verificano, indagano e decidono cosa fare.
- Processi: le procedure che dicono chi fa cosa, con quali priorità e in quanto tempo, quando scatta un incidente.
- Tecnologie: gli strumenti che raccolgono i dati, generano gli alert e aiutano ad automatizzare la risposta.
La parola chiave nascosta nella definizione è "continuo". Un SOC ha senso se copre le 24 ore, perché gli attacchi non rispettano l'orario d'ufficio: molte intrusioni partono di notte, nel weekend o durante le festività, proprio quando in azienda non c'è nessuno a guardare. Un presidio che si ferma alle 18 lascia scoperte le ore in cui l'attaccante preferisce muoversi.
Vale la pena chiarire subito la confusione più comune: il SOC non è il SIEM. Il SIEM è lo strumento che raccoglie e correla i log, il SOC è il team e i processi che usano quello strumento (e altri) per fare sicurezza operativa. Abbiamo dedicato una guida a parte a cos'è un SIEM e come funziona, perché è il cuore tecnologico attorno a cui il SOC lavora.
Cosa fa un SOC: le funzioni
Il lavoro di un SOC non si esaurisce nel "guardare gli allarmi". È un insieme di attività che coprono l'intero ciclo di vita di un incidente, prima, durante e dopo.
- Monitoraggio continuo. Tiene sotto osservazione l'infrastruttura senza interruzioni, per cogliere i segnali nel momento in cui compaiono.
- Detection. Riconosce le attività sospette o malevole tra il flusso enorme di eventi normali.
- Triage degli alert. Separa i falsi positivi dagli allarmi reali e assegna una priorità, per lavorare prima su ciò che conta.
- Investigation. Ricostruisce cosa è successo: da dove è entrato l'attaccante, cosa ha toccato, fin dove è arrivato.
- Incident response. Interviene per contenere e rimediare, dalla macchina da isolare alle credenziali da revocare.
- Threat hunting. Cerca in modo attivo le minacce che sono sfuggite alle regole automatiche, senza aspettare che scatti un alert.
- Gestione delle vulnerabilità. Tiene d'occhio i punti deboli dei sistemi e ne segue la remediation nel tempo.
- Reporting e conformità. Documenta l'attività e produce i report richiesti da normative e standard, dalla NIS2 alle certificazioni di settore.
Il filo conduttore è la continuità: un SOC non è un intervento una tantum, ma un presidio che dura nel tempo e migliora man mano che conosce meglio l'ambiente che sorveglia.
Di cosa è fatto un SOC: i componenti
Dietro le funzioni ci sono componenti concreti, che vale la pena conoscere per capire cosa serve per farne uno.
- Gli analisti, su tre livelli. Il modello più diffuso li organizza per profondità di intervento. Gli analisti di L1 presidiano e fanno il primo triage degli alert. Quelli di L2 approfondiscono le indagini sui casi che superano il primo filtro. Quelli di L3 gestiscono gli incidenti più complessi, fanno threat hunting e mettono a punto le detection.
- Un SIEM. La piattaforma che raccoglie e correla i log e genera gli alert su cui il team lavora. È il centro nevralgico tecnologico del SOC.
- Strumenti di automazione (SOAR). Automatizzano i passaggi ripetitivi con playbook, riducendo il tempo tra l'allarme e l'azione e alleggerendo il carico sugli analisti.
- EDR ed XDR. Le tecnologie che vedono e rispondono su endpoint e ambiente, spesso alimentando il SIEM. Se vuoi capire come si distinguono dai servizi gestiti, c'è il confronto tra EDR, XDR e MDR.
- Threat intelligence. I flussi di informazioni sulle minacce in circolazione, che permettono al SOC di riconoscere in fretta ciò che altri hanno già osservato.
Nessuno di questi componenti da solo fa un SOC. Un SIEM senza analisti che lo guardino resta un archivio di allarmi, e un team senza gli strumenti giusti indaga alla cieca: è la loro combinazione, orchestrata da processi chiari e persone competenti, a produrre il risultato.
Come si misura un SOC: le metriche che contano
Un SOC non si valuta a impressioni, ma con numeri precisi. Tre metriche, in particolare, dicono se sta funzionando.
- MTTD (Mean Time To Detect), il tempo di rilevamento: quanto ci mette il SOC ad accorgersi che è in corso un attacco. È la metrica più importante, perché tutto il resto parte da lì.
- MTTR (Mean Time To Respond), il tempo di risposta: quanto passa tra il rilevamento e il contenimento dell'incidente. Abbiamo spiegato come si abbassa in cos'è l'MTTR e come ridurlo.
- Dwell time, il tempo di permanenza: per quanto un attaccante resta dentro l'ambiente prima di essere scoperto. È il numero che racconta meglio di ogni altro l'efficacia reale del presidio, e lo approfondiamo in cos'è il dwell time.
Perché contano così tanto: tra il momento in cui un attaccante entra e il momento in cui colpisce c'è una finestra, e in quella finestra si gioca tutto. Un SOC efficace esiste per comprimerla, portando la scoperta e la risposta da settimane o mesi a poche ore o minuti. Non a caso queste stesse metriche sono al centro degli obblighi di detection e response che normative come la NIS2 si aspettano da chi vi rientra.
Un esempio rende l'idea. Se un attaccante entra e il dwell time è di tre mesi, ha tutto il tempo di studiare l'ambiente, muoversi lateralmente e preparare il colpo indisturbato. Se lo stesso ingresso viene rilevato in poche ore, la stessa intrusione si ferma prima di fare danni. La differenza tra i due scenari non sta negli strumenti installati, ma nella capacità del SOC di guardare, capire e reagire in fretta.
Quando un'azienda ha bisogno di un SOC?
Non tutte le aziende hanno le stesse esigenze, ma alcuni segnali indicano che il presidio occasionale non basta più. Vale la pena riconoscerli prima che sia un incidente a farlo.
- La superficie di attacco è cresciuta. Più endpoint, più utenti in mobilità, più servizi cloud e più integrazioni significano più porte da tenere d'occhio, e nessuna persona da sola può farlo a mano.
- Gli alert arrivano ma nessuno li presidia fuori orario. Avere strumenti che segnalano non serve se di notte e nel weekend non c'è nessuno a leggerli, ed è proprio in quelle ore che gli attacchi si muovono.
- Ci sono requisiti di conformità. Normative come NIS2 e DORA, e standard come la ISO 27001, si aspettano capacità di detection e response continue e documentate, non controlli sporadici.
- Il dato conta per il business. Se un fermo o una fuga di dati avrebbe un impatto serio su clienti, produzione o reputazione, il costo del presidio va confrontato con il costo di non averlo.
Se anche solo un paio di questi punti descrivono la tua situazione, la domanda smette di essere se serva un SOC e diventa come procurarselo, che è esattamente il tema del prossimo passaggio.
SOC interno o gestito: come si sceglie
La domanda pratica che si pone quasi ogni azienda è se costruire il SOC in casa o affidarlo a un partner. Non c'è una risposta valida per tutti, ma i termini del confronto sono chiari.
Un SOC interno dà controllo diretto e conoscenza profonda del contesto aziendale. Ha però un costo che sorprende molti: per coprire davvero le 24 ore, 7 giorni su 7, serve una rotazione di circa 6 analisti, il che significa nell'ordine di 400.000-600.000 euro l'anno di solo personale, a cui vanno aggiunti strumenti, formazione e la difficoltà, tutt'altro che secondaria, di trovare e trattenere figure rare in un mercato che se le contende. A questo si sommano tempi di avvio lunghi, perché un team non si costruisce in poche settimane.
Un SOC gestito, erogato da un partner nelle forme dell'MSSP, dell'MDR o del SOC as a Service, ribalta il modello: canone prevedibile, team già formato, copertura continua dal primo giorno e tecnologia inclusa. In cambio vanno valutati con attenzione gli SLA di detection e response, il rischio di lock-in sulla piattaforma e la capacità del partner di integrarsi con il contesto specifico dell'azienda. Esiste anche un modello ibrido, con il team interno attivo di giorno e il partner a coprire le ore fuori orario.
Abbiamo messo a confronto pro e contro dei due approcci in SOC interno vs SOC gestito, e analizzato cosa determina il costo di quello gestito in quanto costa un SOC gestito. La scelta, in sintesi, dipende da dimensione, maturità, budget e requisiti di conformità: normative come NIS2 e DORA chiedono detection e response continue, e per molte realtà mid-market il modello gestito è la strada più sostenibile per averle.
L'evoluzione: verso l'Agentic SOC
Il SOC tradizionale ha un limite strutturale: il carico di alert cresce più in fretta di quanto crescano gli analisti disponibili. Il risultato è la fatica da allarmi, dove il rumore rischia di coprire i segnali veri. Da qui nasce l'evoluzione più recente, l'Agentic SOC.
L'idea è mettere l'intelligenza artificiale e gli agenti al lavoro sui passaggi ripetitivi: raccogliere il contesto attorno a un alert, arricchirlo con la threat intelligence, scartare in autonomia il rumore evidente, preparare l'indagine e proporre le prime azioni di risposta. In questo modo gli analisti dedicano il proprio tempo alle decisioni che contano, invece di consumarlo nel triage manuale di migliaia di segnali. L'obiettivo non è sostituire le persone, ma accelerare triage e risposta e restituire ore preziose al giudizio umano.
È la direzione su cui AmagisTech ha costruito il proprio posizionamento: un SOC gestito potenziato da AI e agenti, pensato per il mid-market italiano, su piattaforma aperta perché i dati restino tuoi e leggibili. La piattaforma SIEM al centro, il detection engineering e il presidio continuo sopra, l'automazione a fare da moltiplicatore. Se vuoi vedere come funziona nella pratica, parti dai nostri servizi di observability e SecOps.
In sintesi: un SOC è la combinazione di persone, processi e tecnologie che monitora, rileva e risponde agli incidenti idealmente 24 ore su 24. Le sue funzioni vanno dal monitoraggio al threat hunting, i suoi componenti dagli analisti su tre livelli al SIEM, e si misura con metriche precise come MTTD, MTTR e dwell time. Può essere interno o gestito, con differenze di costo notevoli, e sta evolvendo verso l'Agentic SOC, dove AI e agenti accelerano il lavoro senza togliere alle persone le decisioni. Perché la sicurezza operativa, alla fine, non è mai solo tecnologia: è chi la presidia, e come.
