Due strumenti che sembrano uguali ma non lo sono

Una hunting query e una analytics rule possono contenere esattamente lo stesso KQL e produrre esattamente le stesse righe, eppure l’esame le tratta come oggetti diversi, perché diverso è il loro effetto. La hunting query — sia in advanced hunting di Microsoft Defender XDR sia nella sezione Hunting di Microsoft Sentinel — è uno strumento esplorativo: la lanci a mano contro un’ipotesi (“qualcuno sta usando un binario di sistema per scaricare payload”, “esiste un pattern di logon anomalo fuori orario”) e ottieni un risultato che vive nella tua sessione. Non crea alert, non crea incident, non attiva automation rule né playbook, non finisce in SecurityAlert o SecurityIncident. Se chiudi il browser, il valore prodotto è solo la tua conoscenza.

La analytics rule fa il contrario: gira da sola secondo una pianificazione, e quando la query restituisce risultati sopra soglia genera un alert e, se configurata così, un incident. È l’unico modo per trasformare una capacità individuale in una capacità dell’organizzazione. Il ciclo che l’esame chiede di padroneggiare è quindi: ipotesi → hunting → verifica che il pattern sia ripetibile e a basso rumore → promozione a detection.

Conservare il risultato: bookmark e passaggio all’indagine

Fra caccia e detection c’è un passaggio intermedio che vale punti d’esame: il bookmark di Microsoft Sentinel. Quando una riga di risultato è interessante ma non ancora abbastanza da giustificare una regola, la si salva come bookmark — con note e tag — così resta disponibile ai colleghi e agli altri turni. Un bookmark può poi essere aggiunto a un incident esistente o diventare il punto di partenza di un incident nuovo, portando le sue entity dentro il grafo dell’indagine. È il modo corretto di rispondere alla domanda “come conservo questo risultato di caccia?”: non un export CSV, non uno screenshot in un ticket.

Sulla stessa linea vanno lette le capacità più recenti: hunting graph e ragionamento sul blast radius servono a capire fin dove si estende una compromissione partendo da un’entità; Sentinel Data lake e Sentinel Graph servono a cacciare su volumi e orizzonti temporali che l’analytics tier renderebbe insostenibili; le summary rule pre-aggregano sorgenti verbose in modo che la caccia resti economica; SOC optimization e case management aiutano a decidere dove conviene investire in copertura e a governare il lavoro sui casi. Sono scelte di strategia, non passaggi di menu.

Promuovere in Sentinel o in Defender XDR

La scelta del bersaglio dipende da dove vive il dato. Se la query interroga tabelle del workspace (SecurityEvent, SigninLogs, AuditLogs, AzureActivity, CommonSecurityLog, Syslog), la promozione naturale è una Scheduled analytics rule in Microsoft Sentinel: si definiscono pianificazione, lookback, soglia, entity mapping (account, host, IP, file), custom details, tagging MITRE ATT&CK e logica di raggruppamento degli alert in incident. Se serve latenza minima su un singolo evento si sceglie una regola NRT invece di una Scheduled con frequenza aggressiva.

Se invece la query gira in advanced hunting su tabelle Defender (DeviceProcessEvents, DeviceLogonEvents, EmailEvents, IdentityLogonEvents, CloudAppEvents), la promozione è una custom detection rule in Microsoft Defender XDR: nasce direttamente dalla query salvata, richiede che il risultato esponga le colonne previste — fra cui Timestamp, ReportId e una colonna di entità impattata — e può innescare azioni di risposta sulle entità individuate. La regola vale solo se il risultato è progettato per essere consumato da una macchina, non solo letto da un analista.

Trappole tipiche d’esame

  • La query trova la minaccia ma il SOC non viene avvisato → promuovi a regola: salvare la query fra le hunting query o schedularla come “query preferita” non genera nulla; serve una Scheduled/NRT analytics rule o una custom detection rule.
  • “Salva come custom detection” non è disponibile → colonne mancanti: la query di advanced hunting deve restituire le colonne richieste (Timestamp, ReportId, una colonna di entità); riscrivi la proiezione invece di cambiare tipo di regola.
  • Risultato di caccia da conservare e portare in indagine → bookmark: è l’oggetto pensato per questo, e si aggancia a un incident nuovo o esistente; l’export manuale non è la risposta attesa.
  • L’incident mostra solo testo, l’analista non può pivotare su utente e host → entity mapping: senza mappatura delle entity non c’è correlazione, né grafo d’indagine, né azioni mirate.
  • Serve reagire entro pochi minuti a un singolo evento → NRT rule: una Scheduled rule con finestra molto stretta aumenta costo e rumore senza dare la latenza richiesta.
  • Il segnale è già prodotto da un workload Defender → Microsoft Security rule: per far confluire quegli alert in incident di Sentinel non si riscrive la logica in una Scheduled rule, si abilita la regola di tipo Microsoft Security.
  • Il tuning va fatto prima, non dopo → misura il rumore in hunting: una query che in caccia restituisce centinaia di righe al giorno diventa una regola che seppellisce la coda incident.