Il workbook come superficie di visualizzazione

In Microsoft Sentinel un workbook è una dashboard interattiva costruita sopra query KQL eseguite contro i dati del workspace. Non raccoglie nulla, non decide nulla, non genera nulla: prende tabelle già presenti — SecurityIncident, SecurityAlert, SigninLogs, AuditLogs, AzureActivity, Heartbeat, CommonSecurityLog — e le rende leggibili sotto forma di grafici, tabelle, timeline e filtri parametrici (intervallo temporale, severity, owner, tenant).

Il suo scopo tipico è misurare il lavoro del SOC e comunicarlo: quanti incident sono stati aperti per severity, come si distribuiscono le classificazioni di chiusura (true positive, false positive, benign), quanto tempo passa tra creazione e presa in carico, quali data connector stanno effettivamente ingerendo dati e quali sono muti. Molti data connector portano con sé workbook template pronti, che restano il punto di partenza sensato: si clona il template e si adatta, invece di riscrivere da zero.

La caratteristica che l’esame vuole farti riconoscere è che il workbook è descrittivo e su richiesta. Mostra esattamente ciò che la query gli chiede di mostrare, nell’intervallo che imposti. Non ha trigger, non ha stato, non sa se un dato è utile o inutile.

Cosa un workbook non è

Un workbook non è un meccanismo di detection: se serve un alert o un incident, la risposta è una analytics rule (Scheduled, NRT, Microsoft Security, Fusion, Anomaly, Threat Intelligence). Una query eseguita in un workbook, esattamente come una hunting query, non produce alert.

Un workbook non è nemmeno un meccanismo di risposta: non invia mail, non apre ticket, non isola macchine. Quella catena è automation rule (che orchestra sugli eventi di incident e alert) più playbook (Logic Apps che esegue l’azione).

Infine, un workbook non riduce il costo dei dati. Se il problema è che una query pesante viene rieseguita ogni giorno su volumi enormi, la leva concettualmente corretta è pre-aggregare con una summary rule e far leggere al workbook il risultato aggregato; se il problema è che un dato non serve, la leva è a monte, nella data collection rule associata all’Azure Monitor Agent, o nella scelta del tier di quel dato.

SOC optimization: la raccomandazione

La SOC optimization risponde a una domanda diversa: non “com’è andata”, ma “cosa dovresti cambiare”. È un motore di raccomandazione dentro Microsoft Sentinel che guarda i dati che stai ingerendo e le detection che hai attive, e mette in evidenza due tipi di squilibrio.

Il primo asse è la copertura: rispetto a scenari di minaccia noti e alle tecniche MITRE ATT&CK, indica dove stai raccogliendo il dato ma non hai una regola che lo usi, oppure dove mancano sorgenti per coprire un vettore rilevante. È il caso classico del connector attivo da mesi senza una singola analytics rule sopra.

Il secondo asse è il valore del dato rispetto al costo: tabelle ingerite in volume ma mai toccate da analytics rule, hunting o investigazione. Qui la raccomandazione tipica è ripensare come quel dato viene trattato — smettere di raccoglierlo, filtrarlo alla fonte, o spostarlo su un piano di conservazione meno caro anziché tenerlo nel percorso di analisi.

Sono raccomandazioni, non azioni automatiche: vanno valutate dal team, perché un dato “inutile” per le detection può essere indispensabile per compliance o per l’hunting retrospettivo. Sul piano operativo (dove appaiono, con quale granularità, quali metriche esatte) resta buona regola verificare la documentazione ufficiale, perché è una capacità in evoluzione.

Trappole tipiche d’esame

  • Serve una vista condivisibile con il management su volumi e tempi di gestione degli incident → workbook: è visualizzazione, non detection; una hunting query salvata o una analytics rule non producono una dashboard parametrica.
  • Serve sapere dove la detection coverage è scoperta o dove stai pagando dati inutilizzati → SOC optimization: il workbook mostrerebbe solo ciò che gli chiedi, non ti direbbe cosa manca.
  • Il workbook deve “avvisare” quando una soglia viene superata → analytics rule (+ automation rule/playbook): i workbook non hanno trigger né notifiche.
  • La raccomandazione dice che una tabella non porta valore → l’azione sta nella DCR o nel tier del dato, non nel workbook: si interviene sulla raccolta con Azure Monitor Agent, non sulla dashboard.
  • Domanda che confonde SOC optimization con lo secure score: lo secure score misura la postura di configurazione preventiva, la SOC optimization misura copertura ed economia della detection.
  • Report ricorrente su enormi volumi, lento e costoso → summary rule a monte, workbook sopra il dato aggregato: ottimizzare la query nel workbook non risolve il problema di scala.