SOC h24/7 per conto terzi: persone necessarie, software, competenze e casi reali

Costruire e gestire un SOC (Security Operations Center) h24/7 per conto terzi non significa solo comprare un SIEM e mettere persone in turno. Significa progettare un servizio industriale con SLA, processi di incident response, detection engineering, piattaforme integrate e personale con competenze molto specifiche.

In questo articolo trovi un approccio pratico basato su casi reali pubblici, linee guida istituzionali e un modello numerico per dimensionare il team.

1) Cosa significa davvero “SOC per conto terzi”

Un SOC per conto terzi (MSSP/MDR) deve garantire contemporaneamente:

• monitoraggio continuo multi-cliente;
• triage e risposta a incidenti con SLA contrattuali;
• separazione sicura dei tenant (dati, playbook, visibilità);
• reportistica tecnica e management per ciascun cliente;
• miglioramento continuo delle detection.

Le linee guida NCSC UK insistono su un principio chiave: il modello operativo deve essere proporzionato alla minaccia e alle risorse, non “one size fits all”.

2) Eventi e casi reali utili da studiare

Caso A – Quando gli alert ci sono, ma il processo fallisce: Target (2013)

Il report del Senate Commerce Committee sugli eventi Target mostra un punto fondamentale: avere tool e alert non basta se escalation e decisioni non funzionano. È uno dei casi più citati per spiegare perché governance e processi SOC sono critici tanto quanto la tecnologia.

Fonte: Senate Commerce Committee – staff report sul data breach Target

Caso B – Costruzione progressiva del SOC: NCSC Netherlands

Il factsheet NCSC NL raccomanda di partire piccolo e crescere, iniziando da fonti log essenziali e consolidando processi, ruoli e collaborazione interna. È molto utile per evitare programmi SOC troppo ambiziosi e ingestibili nei primi mesi.

Fonte: NCSC NL – Factsheet “Building a SOC: start small” (PDF)

Caso C – Esempio di SOC nazionale in esercizio: NHS Scotland

NHS Scotland ha pubblicato il proprio National SOC (2025) indicando servizi concreti: monitoraggio, investigazione alert, collaborazione con partner e gestione incidenti. È un esempio reale di SOC multi-organizzazione con coordinamento centrale.

Fonte: NHS Scotland – National Security Operations Centre

3) Quante persone servono davvero per un SOC h24/7 per conto terzi

La domanda corretta non è “quanti analisti mi servono?”, ma:

• quanti clienti e asset devo coprire;
• quali SLA (es. P1 in 15 minuti, P2 in 60 minuti);
• quanta automazione ho già;
• quanti alert/giorno e quanti incidenti/mese;
• che profondità di servizio offro (solo triage o anche IR/forensics).

Regola pratica di dimensionamento (stima operativa)

Per coprire 1 postazione attiva 24/7, nella pratica servono in genere 5-6 FTE (ferie, malattie, formazione, handover, quality).

Quindi:

• 2 postazioni L1 sempre attive = ~10-12 FTE;
• 1 postazione L2 sempre attiva = ~5-6 FTE;
• L3/IR on-call + presenza diurna = ~3-5 FTE equivalenti;
• engineering/detection/platform = ~4-7 FTE;
• management, service delivery, QA/compliance = ~2-4 FTE.

Ordine di grandezza realistico per un SOC terzi h24/7: 24-34 persone per un servizio maturo multi-cliente. Modelli molto “lean” possono scendere, ma con copertura/scope e SLA più limitati.

Nota: questa è una stima ingegneristica (non un numero normativo), utile per budgeting iniziale.

4) Modello ruoli minimo per copertura 24/7

• L1 Analyst (triage): prima analisi alert, validazione, escalation.
• L2 Analyst (investigazione): correlazione, containment guidance, coordinamento tecnico.
• L3 / Incident Responder: incidenti critici, malware analysis, decisioni tecniche avanzate.
• Detection Engineer: use case, tuning, riduzione falsi positivi, regole SIEM/EDR.
• SOC Engineer / Platform Engineer: ingestione log, pipeline dati, affidabilità piattaforma.
• Threat Intel/Hunter: ipotesi di caccia, TTP, priorità investigativa.
• SOC Manager + Service Delivery: SLA, KPI, qualità, governance cliente.

5) Software necessari per un SOC operativo h24/7

Uno stack completo include tipicamente:

• SIEM: Microsoft Sentinel, Splunk Enterprise Security, Elastic Security, IBM QRadar.
• EDR/XDR: Microsoft Defender XDR, CrowdStrike Falcon, SentinelOne Singularity.
• SOAR/Automation: Cortex XSOAR, Splunk SOAR, Tines.
• Case Management: ServiceNow SecOps, TheHive, Jira Service Management.
• Threat Intelligence Platform: MISP, OpenCTI, feed commercial.
• Vulnerability Management: Tenable, Qualys, Rapid7.
• Forensics/IR toolkit: Velociraptor, Volatility, KAPE, Wireshark.
• Log pipeline / data engineering: syslog-ng/rsyslog, Fluent Bit, Kafka (quando necessario).

I log “must-have” per partire subito

Secondo la guida NCSC UK, tra i quick win ci sono:

• log di autenticazione;
• log dei controlli di sicurezza (es. firewall, antimalware, ACL changes);
• log DNS.

Fonte: NCSC UK – Log sources (“must-have logs”)

6) Competenze necessarie (persone prima dei tool)

Le competenze chiave per tenere un SOC davvero operativo h24/7 sono:

• analisi eventi e incident triage;
• network forensics e endpoint forensics;
• incident response tecnico e coordinamento crisi;
• detection engineering (KQL/SPL/EQL, log schema, tuning);
• threat intelligence e mapping ATT&CK;
• scripting/automazione (Python, PowerShell, API);
• cloud security operations (AWS/Azure/M365/GCP);
• comunicazione operativa verso clienti e management.

Per definire ruoli e skill in modo standard, è utile usare il framework NICE di NIST.

Fonte: NIST SP 800-181 Rev.1 (NICE Framework)

7) Processi indispensabili per non “rompere” il 24/7

• Runbook versionati: cosa fare per ogni caso ricorrente (phishing, beaconing C2, account takeover, ransomware behavior).
• Handover strutturato: passaggio turno obbligatorio con stato incidenti e next action.
• Severity model unico: criteri P1/P2/P3 condivisi con clienti.
• SLA e OLA misurabili: tempo presa in carico, contenimento, chiusura, post-mortem.
• QA detection: tuning continuo per abbassare false positive e aumentare coverage reale.

8) KPI minimi da monitorare ogni mese

• MTTD (mean time to detect);
• MTTA (mean time to acknowledge);
• MTTR (mean time to respond/remediate);
• falso positivo per use case;
• copertura log per cliente e asset critici;
• incidenti per severità e causa radice;
• aderenza SLA per cliente.

9) Errore tipico da evitare

L’errore più frequente è costruire il SOC “dai tool in su” invece che “dal servizio in giù”: prima SLA, responsabilità, escalation, competenze e modello operativo; poi tecnologia.

Conclusione

Un SOC h24/7 per conto terzi è una fabbrica di decisioni operative, non una dashboard. Per reggere davvero nel tempo servono: dimensionamento realistico del team, piattaforma integrata, competenze verticali, processi disciplinati e miglioramento continuo.

Se devi partire oggi, la strategia più efficace è:

1. definire il servizio minimo sostenibile (scope + SLA + clienti target);
2. attivare monitoraggio sui log essenziali e 5-10 use case ad alto impatto;
3. costruire gradualmente coverage e profondità IR con metriche mensili.

Riferimenti

• NCSC UK – Building a Security Operations Centre (SOC)
• NCSC UK – Designing an Operating Model
• NCSC UK – Log sources
• NCSC NL – Building a SOC: start small (PDF)
• NHS Scotland – National SOC
• U.S. Senate Commerce Committee – Target breach report release
• NIST SP 800-61 Rev.3 (Incident Response, aprile 2025)
• NIST SP 800-181 Rev.1 (NICE Framework)