Chi rivela ciò che l’alert non rileva?

Una dashboard senza alert non dice necessariamente che non sta accadendo nulla.

Dice che, in quel momento, nessun evento ha superato i criteri con cui abbiamo scelto di osservare l’ambiente.

Gli strumenti di sicurezza osservano ciò che sono stati configurati per riconoscere. Raccolgono eventi, applicano regole, confrontano comportamenti e producono alert quando si verificano determinate condizioni.

Questa capacità è indispensabile, ma non coincide con una visione completa di tutto ciò che accade.

La rete cambia, il modello di rilevamento deve seguirla

Un’infrastruttura non è un ambiente statico.

Cambiano gli asset, le applicazioni, le identità digitali e i servizi utilizzati. Vengono introdotti nuovi fornitori, modificati i privilegi, aperti accessi temporanei e spostati carichi di lavoro. Anche i comportamenti degli utenti cambiano in base ai progetti, alle sedi, agli orari e alle modalità di collaborazione.

Ogni cambiamento modifica ciò che può essere considerato normale.

Se il modello di rilevamento rimane fermo mentre l’ambiente cambia, aumenta progressivamente la distanza tra ciò che accade e ciò che il SOC riesce a interpretare.

Il problema non è soltanto la possibilità di perdere una minaccia. Un modello poco aderente alla rete genera anche rumore, moltiplica gli alert privi di rilevanza e assorbe l’attenzione degli analisti.

La qualità della detection dipende quindi dalla capacità di mantenere allineati ambiente, fonti informative e criteri di osservazione.

Un alert è il risultato di una scelta

Ogni alert nasce da una decisione presa a monte.

Quali fonti devono essere raccolte? Quali eventi meritano di essere correlati? Quali sequenze possono indicare un comportamento anomalo? Quanto deve essere ampio l’intervallo temporale di osservazione? Quali soglie hanno senso per quello specifico ambiente?

Un alert non rappresenta automaticamente la realtà. Rappresenta il risultato delle domande che il sistema è stato preparato a porre e dei dati che ha la possibilità di osservare.

Ogni tecnologia ha infatti un proprio perimetro di visibilità. Comprendere la differenza tra EDR, MDR e SOC significa anche capire quali informazioni vengono raccolte, come possono essere correlate e chi si assume la responsabilità di interpretarle.

Per questo la detection non può dipendere esclusivamente da un prodotto, ma neppure dall’esperienza o dall’intuizione del singolo analista.

L’esperienza umana resta essenziale quando occorre formulare ipotesi, collegare elementi apparentemente distanti e interpretare comportamenti ambigui. Per produrre risultati continui, però, questa esperienza deve diventare metodo.

Dall’osservazione al metodo

Un SOC maturo non si limita a ricevere alert e assegnarli a un analista.

Verifica che le fonti disponibili offrano una copertura coerente con l’ambiente da proteggere. Controlla la qualità della telemetria e individua gli spazi nei quali la visibilità è insufficiente. Aggiorna i casi d’uso quando cambiano la rete, i comportamenti o le tecniche di attacco.

Le baseline comportamentali aiutano a comprendere che cosa sia abituale per un’identità, un sistema o un servizio. La correlazione permette di mettere in relazione eventi che, osservati singolarmente, potrebbero non avere un significato evidente. Il threat hunting introduce una ricerca attiva, guidata da ipotesi, anche quando non esiste ancora una segnalazione esplicita.

A queste attività deve aggiungersi una revisione periodica della capacità di rilevamento.

Quali fonti stanno producendo informazioni utili? Quali use case generano soltanto rumore? Quali cambiamenti dell’infrastruttura richiedono nuove regole? Quali incidenti o anomalie hanno mostrato un limite nel modello esistente?

Misurare soltanto il numero di alert gestiti non risponde a queste domande. Descrive il lavoro svolto, ma non necessariamente la qualità della visibilità ottenuta.

Conoscere anche i propri punti ciechi

Nessun SOC può promettere di vedere ogni attività e riconoscere immediatamente qualsiasi minaccia.

Può però conoscere il perimetro della propria osservazione, dichiararne i limiti e lavorare per ridurre progressivamente le aree non coperte.

Questa consapevolezza cambia il significato dell’assenza di alert.

Una dashboard silenziosa non viene interpretata automaticamente come una prova di sicurezza. Viene letta insieme alla copertura delle fonti, alla qualità dei casi d’uso, all’affidabilità delle baseline e alla conoscenza dell’ambiente.

Un SOC deve quindi saper spiegare che cosa osserva, con quali criteri e attraverso quali dati. Deve anche sapere dove la propria capacità di rilevamento potrebbe essere incompleta.

Assumersi questa responsabilità non significa dichiarare l’infallibilità del sistema. Significa rendere il processo di detection verificabile e migliorabile.

Un SOC che evolve insieme all’ambiente

In Digimetrica consideriamo il SOC una capacità operativa in continua evoluzione.

Non ci limitiamo a osservare gli alert prodotti dagli strumenti. Lavoriamo per mantenere coerenti telemetria, casi d’uso, baseline e processi di analisi rispetto all’ambiente che devono proteggere.

Quando la rete cambia, deve cambiare anche il modo in cui viene osservata. Quando emerge un nuovo comportamento, occorre capire se modifica ciò che consideriamo normale. Quando un segnale viene perso o interpretato tardi, bisogna individuare il limite e trasformarlo in un miglioramento del processo.

La tecnologia fornisce dati e capacità di analisi. Gli analisti portano esperienza, giudizio e comprensione del contesto. Il modello operativo permette a questi elementi di lavorare insieme in modo coerente e ripetibile.

È così che un SOC smette di essere soltanto un luogo nel quale arrivano gli alert e diventa un sistema capace di apprendere dall’ambiente.

Perché la sicurezza non nasce da una dashboard tutta verde.

Nasce dalla capacità di comprendere che cosa stiamo osservando, che cosa potrebbe sfuggirci e quali domande dobbiamo ancora imparare a fare.