Il connettore Windows Security Events via AMA non ti chiede quali eventi vuoi: ti chiede quale set. La scelta è fra quattro opzioni, e sbagliarla si paga in bolletta o in cecità.

I quattro set, e la tabella in cui finiscono

All events raccoglie il log Security senza filtri più i canali AppLocker. Non include Application, System o Setup: per quelli serve un DCR separato.

Common è l’audit trail completo: logon e logoff (4624 e 4634), modifiche ai gruppi di sicurezza, operazioni Kerberos dei domain controller. Serve a ridurre il volume mantenendo la tracciabilità, non a fare detection.

Minimal è l’opposto: pochi eventi che possono indicare una compromissione riuscita, senza audit trail. Contiene 4624 e 4625, logon riusciti e falliti, e 4688, creazione di processo: insieme fanno quasi tutto il volume del set. Non contiene 4634, perché il logoff è importante per l’audit ma non dice nulla su una violazione, e costa.

La destinazione è il punto che genera più ticket. Windows Security Events via AMA scrive nella tabella SecurityEvent, che è quella interrogata dalle regole analitiche built-in. Se invece raccogli il log Security con un DCR generico di tipo Windows Event Logs, gli stessi eventi finiscono nella tabella Event, insieme a System e Application, e nessuna regola built-in li vedrà.

XPath: dove si risparmia davvero

Con il set Custom definisci le query nel DCR, nella forma LogName!XPathQuery:

Security!*[System[(EventID=4648)]]
System!*[System[(Level=1 or Level=2 or Level=3) and (EventID != 6)]]

I limiti che contano. Un DCR di Azure Monitor supporta al massimo 20 espressioni, mentre il cmdlet Get-WinEvent ne regge 23: il test locale può passare e il DCR no. L’XPath disponibile è quello di Windows Event Log, XPath 1.0: position, band e timediff funzionano, starts-with e contains no. I canali Analytic e Debug non sono sottoscrivibili dall’agente, quindi non si raccolgono; e i log su share di rete o percorsi UNC non sono supportati, devono stare su disco locale.

Prova sempre la query prima di metterla in un DCR:

$XPath = '*[System[EventID=1035]]'
Get-WinEvent -LogName 'Application' -FilterXPath $XPath

“No events were found” significa query valida senza riscontri sulla macchina; “The specified query is invalid” significa sintassi rotta.

Windows Event Forwarding: cambia la tabella

Se centralizzi gli eventi con WEF, in Sentinel li porti con il connettore Windows Forwarded Events. Ecco il dettaglio che rompe le detection: quel connettore scrive nella tabella WindowsEvent, non in SecurityEvent. Le regole analitiche built-in per Windows interrogano SecurityEvent, quindi un evento inoltrato non le fa scattare. Se una regola non parte, verifica quale tabella interroga e poi scegli: o raccogli quelle macchine con Windows Security Events via AMA, o riscrivi la regola su WindowsEvent.

Sulla configurazione della subscription WEF lato Windows — collector-initiated o source-initiated, GPO, permessi sul canale — la documentazione Sentinel non entra: è amministrazione Windows e va cercata lì.

Tabelle personalizzate: le regole non negoziabili

Il nome deve terminare in _CL. Il portale aggiunge il suffisso da solo; CLI, PowerShell, ARM e REST no, lo scrivi tu, e il nome dichiarato nello stream del DCR deve combaciare esattamente con quello della tabella. Ogni tabella deve avere una colonna TimeGenerated: se manca, Azure Monitor la aggiunge alla trasformazione. Per gestire le tabelle serve il permesso Microsoft.OperationalInsights/workspaces/*, come da ruolo Log Analytics Contributor.

Il connettore Custom Logs via AMA, in preview, è più rigido: la tabella di destinazione deve avere esattamente due colonne, TimeGenerated di tipo DateTime e RawData di tipo String, che diventa Message se i log arrivano da un log forwarder e non dalla macchina applicativa. Nel campo Transform metti source per non trasformare nulla, oppure la rinomina da RawData a Message nel caso forwarder. Se scegli un tipo di dispositivo dall’elenco, il transform si compila da solo: non toccarlo.

Due dettagli che mordono. Il nome della tabella finisce nella fatturazione: niente informazioni sensibili. E i nomi di colonna devono iniziare con una lettera, stare fra 2 e 45 caratteri e usare solo lettere, cifre e underscore; le colonne custom su tabelle Azure vanno chiuse con _CF.

Conservazione: due piani, due orizzonti

L’analytics tier tiene i dati in interactive retention per 90 giorni di default, estendibili fino a due anni: query illimitate, alte prestazioni, nessun costo per query. Il data lake tier conserva i dati secondari — accessi allo storage, NetFlow, proxy, firewall — fino a 12 anni.

Si configura per tabella, dalla pagina Tables e poi Manage table: Analytics retention da 30 giorni a due anni, Total retention fino a 12 anni. Scegliere il Data Lake tier sposta la tabella solo nel lake, e qui c’è l’avviso da leggere davvero: su quelle tabelle smettono di funzionare alerting, advanced hunting, analytics rules e custom detection rules. Non tutte si possono spostare, del resto: alcune tabelle XDR e di soluzioni Sentinel devono restare nell’analytics tier perché i servizi Microsoft ne hanno bisogno in tempo quasi reale.

Per vedere le impostazioni basta Log Analytics Reader; per cambiarle servono i permessi di scrittura su workspace e tabelle, come da Log Analytics Contributor. Nella stessa pagina, Table insights è lo strumento con cui scopri un connettore muto: Last data received e la scheda delle fluttuazioni confrontano le ultime 24 ore con lo stesso giorno della settimana precedente. Sappi però che la soglia di default richiede almeno il 10 per cento e 1 MB di variazione: una tabella sotto 1 MB al giorno non viene valutata, e può smettere del tutto senza comparire.