Perché modernizzare il SOC è un problema di architettura, non di tool

Un SOC (Security Operations Center) moderno non si progetta accumulando prodotti, ma definendo outcome misurabili e allineando persone, processi e piattaforma per raggiungerli. Come SC-100 architect, il tuo compito è tradurre un requisito (“ridurre il tempo di risposta agli attacchi identity-based”) in una scelta di design difendibile: quale piattaforma, quale livello di automazione, quale governance. L’errore ricorrente è partire dallo strumento; la disciplina corretta parte dal rischio da mitigare e dalla copertura delle tecniche avversarie.

Piattaforma: XDR + SIEM, non uno o l’altro

Il pattern di riferimento Microsoft unifica Microsoft Defender XDR (correlazione nativa di segnali su endpoint, identità, email, cloud app e OT) e Microsoft Sentinel come SIEM/SOAR scalabile per log a lungo termine, threat intelligence e automazione.

  • Defender XDR eccelle nella detection ad alta fedeltà con incident correlation automatica: molti alert vengono già raggruppati in un singolo incidente, riducendo il rumore alla fonte.
  • Sentinel aggiunge normalizzazione (ASIM), hunting KQL, e playbook (Logic Apps) per orchestrare la risposta.

Il trade-off classico: portare tutti i log in Sentinel massimizza la visibilità ma esplode i costi di ingestion. Design raccomandato: log ad alto valore per detection in tier analitico, log voluminosi (firewall, proxy) in Auxiliary/Basic logs o Data Lake per hunting on-demand. Prioritizzi per valore di rilevamento, non per completezza.

Misurare la copertura con MITRE ATT&CK

ATT&CK è la lingua franca per esprimere cosa il SOC è in grado di rilevare. Progettare la copertura significa mappare le analytic rule alle tecniche (es. T1078 Valid Accounts, T1110 Brute Force) e visualizzare i gap sulla matrice.

  • Sentinel espone un MITRE ATT&CK coverage view che confronta regole attive e potenziali contro tattiche e tecniche.
  • La copertura va pesata sul profilo di minaccia dell’organizzazione (threat-informed defense), non massimizzata uniformemente: coprire tecniche irrilevanti per il tuo settore è spreco.

Requisito tipico: “dimostrare miglioramento della detection”. Risposta: definire una baseline di copertura ATT&CK, chiudere i gap sulle tecniche a più alta probabilità/impatto, e tracciare l’evoluzione nel tempo.

Automazione della risposta e riduzione dell’MTTR

L’obiettivo operativo è ridurre MTTD (detection) e soprattutto MTTR (response). Le leve:

  • Automation rules in Sentinel per triage, tagging, assegnazione e soppressione dei falsi positivi.
  • Playbook SOAR per azioni concrete: isolare un device via Defender, disabilitare un utente in Microsoft Entra ID, revocare sessioni, aprire ticket.
  • Automatic attack disruption in Defender XDR, che interviene in-flight (es. contenimento di un account compromesso durante un ransomware) basandosi su segnali ad altissima confidenza.

Il trade-off centrale: automazione vs supervisione umana

Più automazione riduce l’MTTR ma aumenta il rischio di azioni errate ad alto impatto (isolare un server di produzione, bloccare un dirigente durante un negoziato). Il design maturo distingue:

  • Azioni a basso impatto/alta confidenza → automazione completa (arricchimento, blocco IP noto malevolo, quarantena email).
  • Azioni ad alto impatto → human-in-the-loop: il playbook prepara il contenimento ma richiede approvazione (es. Teams/email adaptive card) prima di eseguire.

Questo è un principio di Well-Architected: bilanciare Operational Excellence (velocità, ripetibilità) con Reliability e gestione del rischio operativo. L’automazione totale non è sempre la risposta “più sicura”.

Secure Score e metriche per prioritizzare

Microsoft Secure Score (in Defender) e il Secure Score for Cloud (in Microsoft Defender for Cloud) quantificano la postura preventiva e producono raccomandazioni pesate. Usali come input di prioritizzazione: chiudere una raccomandazione ad alto valore (es. MFA, riduzione superficie d’attacco) spesso previene intere classi di incidenti, riducendo il carico sul SOC a monte.

Integra la governance con Microsoft Purview per il contesto sui dati sensibili: un incidente che tocca dati classificati merita priorità di risposta diversa.

Trappole tipiche d’esame

  • Requisito: “il management vuole dimostrare che il SOC è efficace” con report sul numero di alert gestiti → Raccomanda metriche di outcome (MTTD/MTTR, copertura ATT&CK, incidenti contenuti prima dell’impatto), NON il volume di alert: alto volume misura rumore, non sicurezza.
  • Requisito: ridurre l’MTTR su ransomware in corso → Automatic attack disruption di Defender XDR per contenimento in-flight, non un playbook manuale con approvazione a più passaggi.
  • Requisito: automatizzare la risposta ma senza rischiare downtime su sistemi critici → Human-in-the-loop (approvazione nel playbook) per azioni ad alto impatto; automazione piena solo per azioni a basso impatto/alta confidenza.
  • Requisito: massima visibilità sui log voluminosi entro budget limitato → Auxiliary/Basic logs o Data Lake per hunting on-demand, riservando il tier analitico ai log ad alto valore di detection.
  • Requisito: dimostrare miglioramento della detection nel tempo → Baseline e tracking della copertura MITRE ATT&CK allineata al threat model, non semplice aumento del numero di regole.