Microsoft Sentinel: le Detections-as-Code portano il GitOps nel SOC
Il SOC incontra il GitOpsCon l’aggiornamento di luglio 2026, Microsoft #Sentinel porta la logica #DevOps fin dentro il cuore del rilevamento delle minacce: le regole di detection personalizzate entrano ufficialmente tra i contenuti gestibili come Detections-as-Code (DaC) tramite le Sentinel Repositories, mentre un nuovo pannello Table Insights rende finalmente leggibile a colpo d’occhio lo stato di #salute dell’ingestion. Sono due funzionalità distinte ma complementari, ed entrambe parlano direttamente a chi in azienda gestisce SIEM e pipeline CI/CD con lo stesso approccio.
Detections-as-Code: le regole di rilevamento come contenuto versionatoMicrosoft Sentinel Repositories esisteva già per contenuti come analytics rules, automation rules, hunting queries, parser, playbook e workbook: la novità è che ora anche le regole di detection personalizzate (custom detection rules) rientrano in questo flusso, gestibili tramite la Microsoft Security Bicep extension. Il repository esterno — #GitHub o #Azure DevOps — diventa la single source of truth: qualunque modifica fatta manualmente dal portale di Sentinel viene sovrascritta alla successiva sincronizzazione dal repository.
Per collegare un repository servono permessi precisi, spesso motivo di attrito nei team più strutturati:
ruolo Owner sul resource group che contiene il workspace Sentinel, per creare la connessione;
accesso Collaborator sul repository GitHub, oppure Project Administrator su Azure DevOps;
GitHub Actions abilitate (o Pipelines per Azure DevOps);
per Azure DevOps, la connessione deve risiedere nello stesso tenant del workspace Sentinel.
Ogni workspace Sentinel è limitato a cinque connessioni repository, e ogni resource group a 800 deployment nella sua history — un limite da tenere presente se si pianifica una struttura multi-repo per team o ambienti diversi.
Bicep, non ARM JSON: la scelta consigliataMicrosoft consiglia esplicitamente Bicep rispetto ai template ARM JSON grezzi per descrivere le regole. Un paio di dettagli tecnici da non sottovalutare in fase di migrazione:
i file Bicep non supportano la proprietà id: le regole esportate da Sentinel la includono, e va rimossa manualmente prima della decompilazione;
per una decompilazione pulita da ARM JSON a Bicep conviene forzare lo schema alla versione 2019-04-01;
le connessioni create prima del 1° novembre 2024 non supportano Bicep e vanno rimosse e ricreate per abilitarlo.
Per chi parte da zero, il repository ufficiale SentinelCICD/RepositoriesSampleContent fornisce template di esempio per ogni tipo di contenuto, comprese le funzionalità avanzate delle connessioni repository.
Smart deployments: non ridistribuire ciò che non è cambiatoUna delle frizioni tipiche del content-as-code applicato a un SIEM è il rischio di ridistribuire regole invariate a ogni deploy, resettando ad esempio schedule dinamici delle analytics rule. Sentinel risolve il problema con gli smart deployments: un file CSV nella cartella .sentinel del repository tiene traccia dei commit e il workflow evita di ridistribuire contenuti non modificati dall’ultimo deploy. È abilitato di default sulle nuove connessioni; per disattivarlo (e forzare sempre il deploy completo) si interviene sul file YAML del workflow o della pipeline.
Il flusso operativo tipico diventa quindi: un analista propone una nuova regola di detection in una pull request, il team la revisiona come farebbe con codice applicativo, al merge la pipeline CI/CD (GitHub Actions o Azure Pipelines) distribuisce automaticamente solo le modifiche nel workspace Sentinel collegato — con audit trail completo su chi ha cambiato cosa e quando, cosa che il portale da solo non garantisce con la stessa granularità.
Table Insights: capire l’ingestion senza scrivere KQLLa seconda novità rilevante del mese è Table Insights, un nuovo pannello nella pagina Tables della configurazione di Sentinel (Defender portal → Microsoft Sentinel → Configuration → Tables). Mostra, senza bisogno di query KQL manuali:
il volume di ingestion degli ultimi 30 giorni, suddiviso per tier (Analytics vs Auxiliary/Data Lake);
le variazioni giorno su giorno e settimana su settimana, utili per individuare picchi o cali anomali;
le tabelle che consumano più ingestion, per stimare rapidamente i costi;
i connettori che hanno smesso di inviare dati — spesso il primo sintomo di un problema di raccolta che altrimenti si scopre solo durante un’investigazione, quando è troppo tardi.
Chi preferisce restare in KQL può ottenere una vista equivalente sfruttando il campo Plan della tabella Usage, che permette di scomporre l’ingestion per Analytics, Basic e Auxiliary direttamente in query native — utile per costruire dashboard personalizzate o alert di costo oltre al pannello grafico.
Nuovi connettori datiL’aggiornamento di luglio amplia anche la copertura dei data connector con il supporto nativo per GitHub Enterprise, Agari, Airlock Digital e Gigamon — un’estensione che si allinea bene proprio con l’adozione di Detections-as-Code, dato che GitHub Enterprise diventa ora sia sorgente di log di audit sia repository di regole.
Perché conviene iniziare oraPer un SOC maturo, la combinazione di queste due funzionalità è più significativa della somma delle parti: Detections-as-Code porta revisione tra pari, versionamento e rollback affidabile sulle regole di rilevamento, mentre Table Insights riduce il tempo necessario per accorgersi che una sorgente di log si è interrotta silenziosamente — un problema che, senza query dedicate, spesso passa inosservato per settimane. Chi gestisce già Infrastructure-as-Code su Azure con Bicep o #Terraform troverà il modello concettuale familiare; la parte più delicata resta la migrazione delle regole esistenti dal portale al repository, che conviene pianificare per gruppi di severità o per data source, non tutta insieme.
Fonte: Petri IT Knowledgebase – Microsoft Sentinel Adds Detections-As-Code, Table Insights, and New Data Connectors, con approfondimenti dalla documentazione ufficiale Microsoft Learn su Sentinel Repositories.
