Un Security Operations Center (SOC) è la funzione che coordina le attività operative di sicurezza di un’organizzazione integrando persone, processi e tecnologia. Il suo obiettivo non è semplicemente “guardare gli alert”, ma trasformare la telemetria di endpoint, identità, rete, cloud e applicazioni in rilevazioni utili, investigazioni coerenti e azioni di risposta.
Un SOC moderno lavora su una catena operativa precisa: raccolta dati → detection → triage → investigazione → containment/escalation → recovery → miglioramento delle regole. La qualità del servizio dipende quindi molto più dal processo, dalla copertura della telemetria e dalle competenze degli analisti che dal semplice numero di strumenti installati.
NIST SP 800-61 Rev. 3, pubblicato nel 2025, integra la risposta agli incidenti nel più ampio processo di cybersecurity risk management. Questo approccio riflette bene il ruolo del SOC: detection e response non sono attività isolate, ma componenti di un ciclo continuo di preparazione, protezione, rilevamento, risposta e recupero.
Vuoi passare dalla teoria a un presidio SOC continuativo?
La guida spiega come funziona un SOC. Per valutare monitoraggio, detection, escalation e risposta gestita sulla tua infrastruttura, consulta il servizio dedicato.
Cosa fa realmente un SOC
Centralizza la visibilità
Raccoglie o riceve telemetria da endpoint, identità, sistemi, rete, cloud, SaaS e strumenti di sicurezza. La priorità non è ingerire qualsiasi log, ma acquisire dati che supportino casi d’uso di detection e investigation.
Rileva comportamenti sospetti
Usa regole, analytics, correlazioni, indicatori, threat intelligence e analisi comportamentale per identificare eventi che meritano attenzione.
Esegue triage e prioritizzazione
Distingue falsi positivi, eventi benigni e incidenti reali valutando severità, asset coinvolti, identità, contesto e potenziale impatto.
Investiga
Ricostruisce timeline e catena d’attacco, correla entità, ricerca attività collegate e verifica l’estensione della compromissione.
Coordina containment ed escalation
Applica o attiva procedure predefinite: isolamento di endpoint, blocco di account o indicatori, escalation verso Incident Response e coinvolgimento dei team responsabili.
Migliora continuamente la detection
Ogni incidente, false positive o test di sicurezza produce feedback per regole, playbook, data source, use case e procedure operative.
Il workflow operativo: dalla telemetria all’incidente
- Data onboarding e normalizzazione - Si definiscono le sorgenti utili e il modo in cui i dati vengono raccolti, normalizzati e mantenuti disponibili per detection e investigation.
- Detection engineering - Le minacce rilevanti vengono tradotte in regole, query, analytics e use case, possibilmente mappati a tattiche e tecniche note.
- Alert triage - L’alert viene arricchito con contesto su asset, utenti, indicatori e storico per stimare probabilità e severità.
- Investigation - L’analista verifica scope, sequenza degli eventi, account coinvolti, persistenza, lateral movement ed eventuale impatto.
- Response ed escalation - In base alle regole di ingaggio vengono eseguite azioni automatiche o manuali e, quando necessario, attivato il team di Incident Response.
- Post-incident improvement - Si aggiornano detection, playbook, logging, controlli e knowledge base per evitare che lo stesso pattern rimanga invisibile o generi rumore.
Quali dati dovrebbe monitorare un SOC
Sorgente | Valore per il SOC |
Identity | Sign-in, autenticazioni, MFA, privilegi, account risk, cambi di ruolo, attività anomale su Active Directory e Microsoft Entra ID. |
Endpoint | Processi, file, persistence, network connection, EDR alerts, execution chain, script e comportamenti sospetti. |
Network | Firewall, DNS, proxy, VPN, IDS/IPS, NDR e flussi di rete utili alla ricostruzione delle comunicazioni. |
Cloud e SaaS | Control plane, workload, storage, audit log, configurazioni e attività sulle piattaforme cloud e applicazioni SaaS. |
Email e collaboration | Messaggi, URL, allegati, phishing, account compromise e attività anomale su piattaforme collaborative. |
Applicazioni e sistemi critici | Audit log, accessi, errori di sicurezza e attività amministrative su ERP, database, server e servizi business-critical. |
SIEM, EDR/XDR e SOAR: non sono sinonimi di SOC
Il SOC è una funzione operativa. Gli strumenti supportano il lavoro, ma non lo sostituiscono. Un SIEM centralizza e analizza eventi; EDR/XDR forniscono detection e risposta su endpoint e altri domini; SOAR automatizza workflow e azioni; threat intelligence arricchisce il contesto. Il valore nasce dall’integrazione di questi elementi con processi, responsabilità e capacità di investigazione.
Componente | Funzione principale | Errore comune |
SIEM | Raccolta, normalizzazione, correlazione, analytics e investigation sui log. | “Ho un SIEM, quindi ho un SOC.” |
EDR/XDR | Telemetria, detection, investigation e response su endpoint e domini correlati. | Confondere il prodotto con il processo operativo. |
SOAR | Automazione e orchestrazione di task e playbook. | Automatizzare senza regole di ingaggio e controllo. |
Threat Intelligence | Contesto su minacce, TTP, indicatori e campagne. | Usare feed senza collegarli a use case e asset reali. |
SOC | Persone + processi + tecnologia per operare detection e response. | Misurarlo solo sul numero di alert gestiti. |
I ruoli all’interno di un SOC
Le strutture Tier 1/Tier 2/Tier 3 sono diffuse, ma non sono obbligatorie. Molti team moderni adottano modelli più fluidi o tierless per ridurre handoff e accelerare l’investigazione. I ruoli tipici possono includere:
- SOC Analyst / Security Analyst: triage, investigation e gestione degli alert.
- Detection Engineer: progetta, testa e mantiene use case e regole di detection.
- Threat Hunter: ricerca proattivamente pattern di compromissione non ancora trasformati in alert.
- Incident Responder / DFIR: interviene sugli incidenti confermati, containment, eradication, recovery e analisi forense.
- Security Engineer: integra data source, EDR/XDR, SIEM, automazioni e controlli tecnici.
- SOC Manager / SecOps Lead: governa processi, SLA, metriche, staffing, escalation e miglioramento continuo.
SOC, Blue Team, MDR e Incident Response: differenze
Termine | Definizione operativa |
SOC | Funzione operativa centralizzata per detection, triage, investigation, escalation e miglioramento delle capacità SecOps. |
Blue Team | Concetto più ampio di difesa: include attività preventive e difensive che possono estendersi oltre il perimetro del SOC. |
MDR | Servizio gestito di detection and response erogato da un provider, spesso basato su EDR/XDR e competenze specialistiche. |
Incident Response | Disciplina e processo attivato per gestire un incidente confermato, contenerlo, eradicarlo e ripristinare l’operatività. |
SOC as a Service | Modello esternalizzato in cui una parte o l’intera funzione SOC viene fornita come servizio continuativo. |
Per approfondire le differenze tra tecnologie e servizi, consulta MDR, EDR, EPP e XDR: cosa significano e come si differenziano.
Quando un alert diventa un incidente
Un alert è un segnale generato da una regola o da un controllo; un incidente è un evento di sicurezza che richiede gestione. Il compito del SOC è evitare sia la sottovalutazione dei segnali reali sia l’escalation indiscriminata del rumore. Per questo servono criteri di severità, asset criticality, identity context, confidence, scope e regole di ingaggio.
Quando l’investigazione conferma una compromissione, il SOC deve poter attivare un processo strutturato di Incident Response con ruoli, procedure ed escalation già definiti.
Quali metriche usare per valutare un SOC
MTTD e MTTR sono utili, ma non sufficienti. Un SOC maturo misura anche copertura, qualità delle detection e capacità di chiudere il ciclo di miglioramento.
Metrica | Cosa misura |
Detection coverage | Quali tecniche, asset e scenari prioritari sono effettivamente coperti dai use case. |
False positive rate | Quanto rumore producono le regole e quanta capacità analitica viene sprecata. |
Time to triage / investigate | Quanto tempo serve per qualificare e comprendere un evento. |
Escalation quality | Percentuale di escalation corrette, complete e con contesto sufficiente. |
Data source health | Disponibilità, completezza e qualità delle sorgenti di telemetria critiche. |
Playbook effectiveness | Quante attività ripetitive sono standardizzate e quanto riducono errori e tempi. |
Lessons learned closure | Quanto rapidamente un incidente produce miglioramenti concreti su detection, logging e controlli. |
SOC interno o SOC as a Service?
La scelta non dipende solo dalla dimensione aziendale. Devono essere valutati copertura oraria, disponibilità di competenze, volume e qualità della telemetria, strumenti esistenti, SLA, responsabilità e capacità di risposta. Un SOC interno offre controllo diretto ma richiede staffing, processi, piattaforme e continuità operativa; un SOC as a Service riduce il carico di costruzione e gestione, ma richiede una chiara definizione di scope, escalation e regole di ingaggio.
Per valutare il modello gestito, consulta SOC as a Service Nexsys.
Il SOC non sostituisce il programma di sicurezza
Un SOC efficace non compensa controlli fondamentali assenti. Patch management, hardening, MFA, identity governance, backup, segmentazione, endpoint protection, vulnerability management e formazione restano responsabilità del programma di sicurezza e dei team competenti. Il SOC osserva e reagisce: la riduzione del rischio richiede che le evidenze prodotte vengano trasformate in remediation.
Per questo la funzione SecOps deve integrarsi con Endpoint Protection, Risk Assessment e consulenza cybersecurity.
Formare le competenze operative del SOC
La tecnologia non elimina la necessità di competenze analitiche. Il Corso Blue Team Nexsys lavora su SOC operations, detection e threat hunting; il Corso Incident Responder approfondisce gestione dell’incidente e DFIR. Le due aree sono complementari ma non coincidenti.
Valuta copertura, telemetria e capacità di risposta
Un SOC utile parte dai casi d’uso e dagli asset critici, non dall’accumulo di log. Il perimetro va costruito su ciò che deve essere rilevato, investigato ed eventualmente contenuto.
FAQ sul Security Operations Center
Che cos’è un Security Operations Center (SOC)?
È una funzione centralizzata che integra persone, processi e tecnologie per raccogliere telemetria, rilevare attività sospette, eseguire triage e investigation, coordinare la risposta e migliorare continuamente le capacità di detection.
Qual è la differenza tra SOC e SIEM?
Il SOC è la funzione operativa; il SIEM è una piattaforma che raccoglie, normalizza e analizza eventi di sicurezza. Un SIEM può supportare un SOC, ma installare un SIEM non significa avere automaticamente un SOC efficace.
SOC e Blue Team sono la stessa cosa?
No. Il Blue Team rappresenta in senso ampio la componente difensiva della sicurezza. Il SOC è una funzione operativa specifica focalizzata soprattutto su monitoring, detection, triage, investigation ed escalation.
Quali strumenti usa un SOC?
Dipende dall’architettura, ma tipicamente SIEM, EDR/XDR, SOAR, threat intelligence, identity security, network telemetry, cloud security e strumenti di case management. Gli strumenti devono essere collegati a processi e casi d’uso di detection.
Un SOC deve essere operativo 24/7?
Non necessariamente in ogni organizzazione. La copertura deve essere definita in base a rischio, criticità degli asset, requisiti operativi e SLA. Per ambienti critici o esposti globalmente può essere necessario un presidio continuativo.
Qual è la differenza tra SOC e MDR?
Il SOC è una funzione di security operations; MDR è un servizio gestito di detection and response fornito da un provider. Un servizio MDR può essere una componente di un SOC esterno o integrarsi con un SOC interno.
Cosa succede quando il SOC conferma un incidente?
Il SOC esegue o attiva le azioni previste dalle regole di ingaggio, raccoglie il contesto e scala verso il processo di Incident Response per containment, eradication, recovery e attività post-incidente.
Quali metriche sono importanti per un SOC?
Oltre ai tempi di rilevamento e risposta, sono rilevanti detection coverage, tasso di falsi positivi, qualità delle escalation, salute delle sorgenti dati, efficacia dei playbook e chiusura delle azioni di miglioramento post-incidente.
Porta il SOC dal monitoraggio alla risposta operativa
Il valore di un SOC si misura nella capacità di collegare telemetria, detection, investigation, escalation e remediation. La landing dedicata descrive il modello SOC gestito Nexsys.