Progettare la strategia di detection: quale segnale per quale minaccia

Da architetto di sicurezza, il tuo compito su SC-100 non è “attivare più regole possibili”, ma mappare ogni tipologia di detection al tipo di minaccia che intende coprire, bilanciando copertura MITRE ATT&CK e rumore operativo. In un’architettura moderna incentrata su Microsoft Sentinel e alimentata dalla telemetria di Microsoft Defender XDR, hai a disposizione quattro leve di detection con caratteristiche molto diverse: analytics rules pianificate, near-real-time (NRT), Fusion e UEBA.

Analytics rules: scheduled vs near-real-time

Le scheduled analytics rules eseguono una query KQL a intervalli definiti (es. ogni 5 minuti su una finestra di lookback). Sono il cavallo di battaglia: massima flessibilità, correlazione cross-table, aggregazioni e soglie. Il prezzo è la latenza (dipende dalla frequenza) e il carico di query sul workspace.

Le regole near-real-time (NRT) girano una volta al minuto sui dati in ingestion, con latenza minima. Vanno riservate a scenari dove ogni secondo conta — modifiche a policy privilegiate, disabilitazione di controlli di sicurezza, creazione di regole di forwarding malevole. Ricorda i limiti architetturali: una NRT interroga una sola tabella, senza join complessi né lookback storico ampio. Se il requisito impone correlazione multi-sorgente, la NRT non è la risposta.

Trade-off di design: non usare NRT per tutto “perché è più veloce”. La copertura di tecniche articolate (multi-stage) richiede correlazione, quindi scheduled o Fusion.

Fusion: correlazione multi-stage a basso rumore

Fusion è un motore di correlazione basato su machine learning che combina alert a bassa fedeltà provenienti da fonti diverse (Sentinel, Defender XDR, Microsoft Defender for Cloud) in un incident multi-stage ad alta fedeltà, spesso allineato alla kill chain. Il suo valore è produrre pochi incident, molto affidabili, riducendo l’alert fatigue. È la scelta raccomandata quando il requisito è “individuare campagne che attraversano identità, endpoint e cloud” senza sommergere il SOC. Non lo tuni regola per regola: lo abiliti e ti affidi al modello, il che significa anche minore controllo esplicito sulle singole logiche.

UEBA: anomalie comportamentali, non firme

User and Entity Behavior Analytics costruisce una baseline per utente/host/entità e segnala deviazioni (accesso a orari anomali, geografie inusuali, volumi di dati fuori norma). Copre ciò che le firme statiche non vedono: insider threat, account compromessi, credential abuse. Va inteso come arricchimento e sorgente di investigazione (tabelle BehaviorAnalytics, IdentityInfo) più che come detection stand-alone: da solo tende a generare falsi positivi, quindi si combina con analytics rules che ne consumano gli score.

Advanced hunting KQL cross-workload

L’advanced hunting è la modalità proattiva e ipotesi-guidata: non aspetti l’alert, formuli un’ipotesi (“un attaccante ha usato questa tecnica?”) e la validi in KQL. In Defender XDR interroghi DeviceProcessEvents, IdentityLogonEvents, EmailEvents, CloudAppEvents; in Sentinel unifichi anche log di rete e infrastruttura. Il pattern architetturale corretto è promuovere hunt di valore a detection: una query di hunting che identifica ripetutamente attività malevola diventa una custom analytics rule, chiudendo il ciclo hunting → detection.

Il trade-off centrale: falsi positivi vs copertura

Ogni detection vive sull’asse coverage / signal-to-noise. Massima copertura con tutte le regole al massimo della sensibilità = SOC paralizzato dai falsi positivi e alert ignorati (rischio peggiore del gap). L’approccio da architetto è risk-based: parti dalle tecniche MITRE ATT&CK rilevanti per il tuo threat model, verifica la copertura con la MITRE ATT&CK coverage matrix integrata in Sentinel, e attiva/tuni le regole per colmare i gap prioritari, non per accendere tutto. Questo si allinea al pilastro Security dell’Azure Well-Architected Framework (detection proporzionata al rischio) e ne rispetta Operational Excellence (processi sostenibili) e Cost/Performance Efficiency (query e ingestion hanno un costo reale nel workspace).

Trappole tipiche d’esame

  • “Abilitare tutte le analytics rules per massimizzare la sicurezza” → NO. Raccomanda un approccio risk-based con tuning e mappatura esplicita alle tecniche MITRE ATT&CK; troppe regole non tunate producono alert fatigue e degradano la detection reale.
  • Requisito: rilevare in tempo quasi reale la disabilitazione di un controllo di sicurezza su una singola sorgente → NRT analytics rule, non scheduled: latenza al minuto senza attendere l’intervallo.
  • Requisito: correlare alert a bassa fedeltà tra identità, endpoint e cloud in un incident multi-stage riducendo il rumore → abilita Fusion, non moltiplicare regole scheduled.
  • Requisito: individuare account compromessi o insider con accessi anomali per orario/geografia → UEBA, arricchito da analytics rules che consumano i behavior score; le firme statiche non colgono le anomalie comportamentali.
  • Requisito: cacciare proattivamente una tecnica specifica su più workload prima che scatti un alert → advanced hunting KQL cross-workload, poi promuovi la query efficace a custom detection rule.