Scheduled: il tipo che copre quasi tutto

Una Scheduled analytics rule è una query KQL che Microsoft Sentinel esegue a intervalli regolari su una finestra di lookback. È il tipo più flessibile: puoi correlare tabelle diverse con una join, arricchire con una watchlist, aggregare con summarize, applicare soglie sul numero di risultati e usare l’event grouping per decidere se produrre un alert per ogni riga o un alert unico per esecuzione. Tutto ciò che non ha un vincolo forte di latenza o di correlazione statistica si scrive qui: accessi anomali su SigninLogs, esecuzioni sospette su DeviceProcessEvents, pattern su SecurityEvent o CommonSecurityLog.

Il prezzo della flessibilità è la latenza: fra l’evento e l’alert passano il tempo di ingestion più l’attesa della prossima esecuzione. Va curato anche il rapporto fra frequenza e lookback. Se la finestra è più ampia dell’intervallo, gli stessi eventi vengono valutati più volte e generano alert duplicati; se è più stretta, alcuni eventi non vengono mai guardati. Su sorgenti molto voluminose e a basso valore unitario la risposta corretta non è alzare la frequenza, ma pre-aggregare con una summary rule e far girare la detection sul dato riassunto.

NRT: latenza minima, query vincolata

Le regole NRT (near-real-time) esistono per un solo motivo: ridurre il tempo fra evento e alert. Vengono valutate con cadenza fissa e molto ravvicinata, senza che tu possa impostare frequenza e periodo. In cambio la query è deliberatamente più povera di quella di una Scheduled: sono ammessi costrutti limitati e tipicamente una sola sorgente, e il numero di regole NRT per workspace è contenuto. L’elenco preciso dei costrutti supportati cambia nel tempo: la regola operativa da portare all’esame è che se la detection ha bisogno di join, union, aggregazioni complesse o lookup su watchlist, NRT non è la strada, indipendentemente da quanto sia urgente.

Scegli NRT per pochi casi ad altissimo valore e a segnale singolo: creazione di un account con privilegi elevati, disabilitazione di un controllo di sicurezza, modifica di una regola critica. Per tutto il resto la Scheduled resta il default.

Microsoft Security, Fusion, Anomaly, Threat Intelligence

Le regole Microsoft Security non contengono KQL: promuovono automaticamente ad incident gli alert generati dai prodotti Microsoft connessi, con filtri per prodotto e severità. Sono utili quando vuoi che un alert di Microsoft Defender for Cloud o di Microsoft Entra ID Protection compaia come incident in Sentinel. Il punto di attenzione è la sovrapposizione con il connettore Microsoft Defender XDR, che sincronizza già gli incident: tenere attive entrambe le vie sugli stessi prodotti produce incident doppi.

Fusion è la detection di attacchi multistadio: correla con machine learning alert e segnali provenienti da prodotti diversi e produce pochi incident ad alta fedeltà, che nessuna singola query avrebbe visto. Non si personalizza scrivendo KQL: si governa abilitandola e, se serve, escludendo pattern rumorosi. Le regole Anomaly sono template ML preconfezionati che descrivono comportamenti fuori scala rispetto a una baseline; le anomalie prodotte servono soprattutto come contesto per indagine e hunting, non come coda di incident da triare, e si tarano duplicando la regola e lavorando sulle soglie prima di portarla in produzione.

Le regole Threat Intelligence confrontano i log con gli indicatori (IP, domini, URL, hash) e sollevano un alert al match. La regola nativa lavora sul feed Microsoft; per gli indicatori che hai importato tu nel workspace, il pattern classico resta una Scheduled che fa join fra ThreatIntelligenceIndicator e la tabella di traffico o di email pertinente.

Entity mapping e incident grouping: da alert a incident lavorabile

Una query che restituisce righe corrette ma non mappate produce un alert cieco. L’entity mapping associa le colonne del risultato a entità riconosciute (Account, Host, IP, URL, FileHash): è ciò che alimenta l’investigation graph, il collegamento con UEBA, le azioni di risposta e la ricerca del blast radius. I custom details portano nell’alert i campi di business che l’analista leggerebbe altrimenti solo riaprendo la query.

L’incident grouping decide invece quanti incident nascono dagli alert. Puoi raggruppare gli alert della stessa regola dentro una finestra temporale, per tutte le entità o solo per quelle scelte, e stabilire se un incident già chiuso debba riaprirsi. È la leva giusta contro una campagna che genera centinaia di alert identici: si raggruppa per entità comune invece di alzare la soglia e perdere visibilità.

Trappole tipiche d’esame

  • Serve reagire in meno di un minuto a un evento singolo → NRT, non Scheduled a frequenza minima: la Scheduled non scende sotto una cadenza di alcuni minuti; NRT esiste proprio per questo caso, accettandone i vincoli sulla query.
  • La detection richiede join, union o lookup su watchlist → Scheduled, anche se lo scenario parla di urgenza: i limiti della query NRT vengono prima del requisito di latenza; se non puoi scrivere la logica, il tipo è sbagliato.
  • Gli incident di Defender XDR devono arrivare in Sentinel → connettore Defender XDR, disattivando le Microsoft Security rule sugli stessi prodotti: tenerle entrambe attive genera incident duplicati per lo stesso alert.
  • Individuare un attacco multistadio che nessuna singola regola vede → Fusion, non una Scheduled con soglie più basse: Fusion correla segnali di prodotti diversi e non si personalizza in KQL; si interviene escludendo pattern rumorosi.
  • Una regola ML fa troppo rumore → duplicare la regola Anomaly e tarare le soglie fuori produzione, non disabilitarla: e ricorda che le anomalie sono contesto per l’indagine, non una coda di incident.
  • Match su indicatori importati dal proprio feed TI → Scheduled con join su ThreatIntelligenceIndicator: la regola Threat Intelligence nativa lavora sul feed Microsoft, non sui tuoi indicatori custom.
  • L’analista non riesce a pivotare né a lanciare azioni dall’alert → manca l’entity mapping: senza entità mappate l’alert non alimenta investigation graph, UEBA e automazioni, per quanto la query sia corretta.