Da hunting query a detection: cosa cambia

In advanced hunting scrivi KQL sulle tabelle di Microsoft Defender XDR — DeviceProcessEvents, DeviceNetworkEvents, IdentityLogonEvents, EmailEvents, CloudAppEvents — e ottieni una tabella di risultati. Quel risultato vive solo finché lo guardi: una hunting query, anche salvata e condivisa con il team, non genera alert, non apre incident e non innesca alcuna azione. È uno strumento d’indagine, non un controllo.

Una custom detection rule è la stessa query promossa a controllo permanente: Defender XDR la esegue a intervalli regolari e ogni riga restituita diventa un alert, con i metadati che hai definito tu, correlato agli altri segnali nella logica di incident del portale. È il ponte fra “ho trovato un pattern durante un’indagine” e “voglio essere avvisato ogni volta che ricapita”.

I requisiti della query: Timestamp, ReportId, entità

La query non può restituire qualsiasi cosa. Timestamp dice quando è avvenuto l’evento e permette alla regola di collocare l’alert nel tempo e di lavorare sulla finestra di lookback corretta. ReportId identifica il singolo record: insieme al Timestamp forma la chiave che evita di rigenerare all’infinito lo stesso alert e consente all’analista di risalire all’evento originario. Una colonna di entità — DeviceId, AccountObjectId, AccountSid, AccountUpn, un hash come SHA1, o RecipientEmailAddress per la posta — dice alla regola su cosa sta scattando. Senza quella colonna la regola non sa a quale device, utente, file o messaggio riferire l’alert e non può offrirti azioni su quell’entità.

Da qui l’errore più frequente: un summarize che aggrega e scarta Timestamp e ReportId produce una query valida in hunting ma inutilizzabile come detection. Se aggreghi, quelle colonne devono ricomparire nel risultato finale.

Frequenza, alert e azioni di risposta

Scegli ogni quanto la regola viene eseguita: dalla modalità continuous (NRT), pensata per la reazione quasi immediata, fino a esecuzioni periodiche più diradate. A ogni frequenza corrisponde una finestra di lookback coerente, così nessun evento cade fra due esecuzioni. La modalità continua ha vincoli sulla forma della query: se la logica non è compatibile si ripiega su una frequenza schedulata — verifica sulla documentazione ufficiale quali costrutti sono ammessi.

I metadati dell’alert (titolo, severity, categoria, tecnica MITRE ATT&CK, descrizione, azioni consigliate) li decidi tu: è ciò che il primo livello leggerà in coda, quindi vanno scritti pensando a chi farà triage.

Le azioni di risposta collegabili dipendono dalle entità restituite: con un device puoi isolare la macchina, raccogliere il pacchetto d’indagine, avviare uno scan o limitare l’esecuzione delle applicazioni; con un file metterlo in quarantena; con un account forzare il reset password, disabilitarlo o marcarlo come compromesso; con un messaggio email spostarlo o eliminarlo. Le regole basate su device si possono limitare a specifici device group, utile per un rollout graduale.

Gestione nel tempo

Una regola non è “fatta e finita”: puoi eseguirla su richiesta, disattivarla, modificarla o eliminarla, e ispezionare gli alert generati per misurarne la precisione. Il tuning si fa sulla query, non chiudendo alert a mano: finché la condizione resta vera, ogni esecuzione ripropone il segnale. Creazione e modifica richiedono i permessi adeguati nel modello RBAC di Defender XDR.

Trappole tipiche d’esame

  • Query di hunting già collaudata → non basta per creare la regola: deve restituire Timestamp e ReportId; se un summarize li elimina, la creazione fallisce anche con logica di detection corretta.
  • Serve isolare il device colpito → serve la colonna dell’entità: senza DeviceId (o l’equivalente per utente, file, email) l’azione su quell’entità non è disponibile. Si corregge la query, non si cerca l’azione altrove.
  • “Deve reagire in pochi minuti” → frequenza continuous (NRT), non oraria: se però la query non è compatibile con la modalità continua si scende a una frequenza schedulata, non si finge che sia real-time.
  • Il segnale sta in una tabella del workspace di Microsoft Sentinel (SecurityEvent, SigninLogs, CommonSecurityLog) → Scheduled analytics rule: la custom detection rule nasce sui segnali di Defender XDR; per la telemetria raccolta via Azure Monitor Agent e data collection rule il tipo di regola atteso è quello di Sentinel.
  • “Misurare l’impatto senza agire” → non confonderlo con ASR: la modalità Audit esiste per le attack surface reduction rule; per una custom detection si crea la regola senza azioni di risposta e si osservano gli alert prodotti.
  • Troppi falsi positivi → tuning della query o scope sui device group: disattivare la regola azzera la copertura, e chiudere gli alert in blocco non impedisce che vengano rigenerati alla prossima esecuzione.