Perché il KQL interattivo non basta

Una hunting query interattiva funziona finché i dati sono recenti: poche settimane di storico, risposta in secondi, iterazione rapida sull’ipotesi. La caccia reale incontra però due limiti. Il primo è economico: quando emerge un nuovo indicatore, la domanda “l’abbiamo mai visto?” guarda indietro di mesi o anni, ma tenere anni di log di firewall e proxy nell’analytics tier di Microsoft Sentinel costa più del valore che producono. Il secondo è espressivo: il KQL filtra, aggrega e correla benissimo, ma non addestra un modello, non chiama un servizio di enrichment esterno e non lascia un documento riproducibile.

Data lake, summary rule, notebook e Sentinel graph rispondono a questi limiti: all’esame conta sapere quale strumento risolve quale problema.

Data lake e KQL job: lo storico a basso costo

Il Sentinel data lake è un tier di archiviazione pensato per volumi grandi e accessi poco frequenti: ci finiscono i dati verbosi e a basso valore per singola riga — telemetria di rete, log applicativi, sorgenti conservate per compliance — che comunque vuoi poter interrogare. Non cambia solo il prezzo, cambia il modello d’uso: sul data lake si eseguono KQL job, interrogazioni asincrone che scandiscono finestre temporali molto ampie e producono un risultato riutilizzabile. Non è la sede della detection in tempo reale — quella resta alle analytics rule sui dati caldi — ma è la sede del retro-hunting: cerchi un IoC su un anno di storico e porti nell’analytics tier solo le righe rilevanti. Il criterio è semplice: dato che serve ora e continuamente, analytics tier; dato che serve raramente ma su orizzonti lunghi, data lake.

Summary rule: pagare la scansione una volta sola

La summary rule attacca lo stesso problema da un’altra angolazione. Una tabella verbosa come CommonSecurityLog o Syslog viene interrogata quasi sempre con le stesse aggregazioni: conteggi per host, destinazione, utente. Invece di far ripetere quella scansione a ogni analytics rule, workbook e hunting query, la summary rule la esegue una volta su base pianificata e materializza il risultato in una tabella compatta. Le query successive girano sull’aggregato: molti meno dati scansionati, latenza più bassa, costi più prevedibili, e l’aggregato si conserva a lungo mentre il dettaglio grezzo finisce nel tier economico. Il trade-off è la granularità: nell’aggregato il singolo evento non c’è più, quindi va progettato sapendo quali dimensioni serviranno all’indagine.

Notebook e Sentinel graph: oltre il KQL

Il notebook porta nel SOC l’ecosistema Python. Combina in un unico documento codice, risultati e narrativa, e copre tre cose che il KQL non fa: analisi statistiche o di machine learning (clustering di beaconing, rilevazione di outlier), arricchimenti custom verso API di terze parti, e la documentazione riproducibile di un’indagine, che un collega rilancia cambiando solo l’entità di partenza. Un notebook, però, non è un meccanismo di detection: non genera incident e qualcuno deve lanciarlo.

Il Sentinel graph guarda invece alle relazioni. Le tabelle rispondono a “cosa è successo”; il grafo risponde a “cosa è connesso a cosa”: quali identità, dispositivi, mailbox e risorse cloud sono legate a un’entità compromessa e attraverso quali percorsi. È lo strumento per valutare il blast radius — l’estensione potenziale di una compromissione — e decidere il perimetro del contenimento, invece di ricostruirlo a mano con una catena di join.

Trappole tipiche d’esame

  • Due anni di log per compliance con ricerche sporadiche → data lake, non retention estesa dell’analytics tier: la retention lunga sui dati caldi soddisfa il requisito, ma è la risposta cara quando le ricerche sono rare.
  • “Cercare l’indicatore su tutto lo storico” e “la detection deve scattare subito” → due strumenti diversi: KQL job sul data lake per il retro-hunting, analytics rule NRT o Scheduled sui dati caldi per la detection.
  • Query e workbook lenti su una tabella molto verbosa → summary rule, non tagliare la sorgente: pre-aggregare riduce la scansione mantenendo il dato; abbassare la retention o spegnere il connettore taglia il costo distruggendo la visibilità.
  • Serve un modello di ML o un arricchimento via API esterna → notebook, non KQL: ma il notebook produce analisi, non alert. Se la domanda chiede una rilevazione ricorrente e automatica, la risposta è una analytics rule.
  • “Quali altre risorse può raggiungere l’account compromesso?” → Sentinel graph e blast radius: la domanda è sulle relazioni fra entità, non su un conteggio di eventi ricostruito a mano.
  • Hunting query che si dimostra affidabile → convertila in regola: una hunting query non genera alert. In Microsoft Sentinel diventa una analytics rule; in Microsoft Defender XDR una custom detection rule, che deve restituire le colonne richieste (fra cui Timestamp, ReportId e una colonna di entità).