Dove atterra un log è una decisione di costo

Ogni telemetria che entra nel SOC si paga due volte: all’ingestion e per la conservazione. Per questo “in quale tier metto questa tabella” è una domanda economica prima che tecnica, ed è così che l’esame la formula: uno scenario dichiara un volume, una frequenza d’uso e un requisito di conservazione, e chiede la collocazione corretta. Il criterio si riduce a due sotto-domande — con che frequenza interrogo questo dato, e mi serve per una detection attiva? Se la risposta alla seconda è sì, la discussione sul risparmio finisce lì: il dato deve stare dove le regole riescono a leggerlo.

Tre destinazioni, tre profili d’uso

Il tier di analisi ospita ciò che il SOC tocca ogni giorno: SecurityEvent, SigninLogs, AuditLogs, SecurityAlert, i segnali su cui girano le analytics rule Scheduled e NRT, l’hunting interattivo, i workbook, le indagini sugli incident. È il tier più caro ed è anche l’unico completo: KQL senza limitazioni, alerting, correlazione, mapping delle entità.

Il tier a costo ridotto è pensato per il dato molto verboso e consultato di rado — firewall loquaci in CommonSecurityLog, Syslog applicativo, log di rete che servono solo quando un’indagine arriva fin lì. Costa molto meno da ingerire ma non è di prima classe: capacità di query ridotte, nessuna detection attiva costruita sopra. È il tier del “lo tengo perché prima o poi mi servirà come contesto”, non del “voglio essere avvisato”.

Il Microsoft Sentinel data lake è la terza collocazione e copre due esigenze che il tier di analisi serve male: conservare anni di dati a costo sostenibile per requisiti di compliance o di indagine, e sottoporre grandi volumi di storico ad analisi retrospettiva — un IOC pubblicato oggi ma attivo da mesi, la ricostruzione del blast radius, elaborazioni assistite. In sintesi: il tier di analisi è il presente operativo, il lake è la memoria lunga.

Defender XDR ha il suo orologio

Un errore frequente è ragionare come se esistesse un unico serbatoio. Le tabelle di advanced hunting in Microsoft Defender XDR — DeviceProcessEvents, DeviceNetworkEvents, EmailEvents, IdentityLogonEvents, CloudAppEvents — vivono con una finestra di retention propria e relativamente breve (verifica il valore corrente sulla documentazione ufficiale): ottime per la caccia sugli ultimi giorni e per costruire una custom detection rule, inadatte a rispondere a “cosa faceva questo host un anno fa”. Se quel requisito esiste, il dato va portato dove la conservazione lunga è prevista, cioè Sentinel e il suo lake. Simmetricamente, “chi ha fatto cosa e quando” sulle attività Microsoft 365 è una domanda da Purview Audit, non un problema di tier di Sentinel.

Come si applica il criterio

Prima di declassare una tabella, verifica se il volume si può ridurre alla sorgente: le data collection rule dell’Azure Monitor Agent filtrano e trasformano prima dell’ingestion, ed è spesso la leva più efficace. Se ti serve solo l’aggregato di un flusso enorme — quanti tentativi di logon per host al giorno, quali destinazioni contattate — valuta una summary rule: il dettaglio resta nel tier economico o nel lake, mentre la sintesi, piccola e interrogabile, alimenta detection e dashboard. Per il dato già archiviato esistono meccanismi di ricerca sullo storico: un’indagine puntuale non impone di riportare tutto nel tier di analisi. Infine, la SOC optimization segnala dove stai spendendo senza copertura di detection, ed è la lente per rivedere periodicamente queste scelte invece di deciderle una volta sola al deployment.

Trappole tipiche d’esame

  • Detection quasi in tempo reale su una tabella molto verbosa → tier di analisi, con filtro in data collection rule: un tier a costo ridotto non alimenta una analytics rule; se serve l’alert il dato sta nel tier di analisi, e il risparmio si ottiene filtrando alla sorgente.
  • Conservazione pluriennale per compliance, consultazione rarissima → conservazione a lungo termine o data lake: alzare la retention del tier di analisi soddisfa il requisito ma è la risposta sbagliata sul costo, ed è il distrattore classico.
  • Indagine su un IOC vecchio di mesi → ricerca sullo storico o query sul data lake: non serve reingerire tutto nel tier di analisi per una singola caccia retrospettiva.
  • “Teniamo tutto in advanced hunting di Defender XDR” → finestra troppo breve: advanced hunting non è un archivio; oltre la sua retention il dato va portato in Sentinel.
  • Serve solo un trend o un conteggio su un volume enorme → summary rule: l’aggregato sposta il costo dal dettaglio alla sintesi senza perdere la capacità di fare detection.
  • “Chi ha aperto quella mailbox sei mesi fa” → Purview Audit: è un requisito di audit trail, non una scelta di tier di Sentinel.