SIEM e security observability: le differenze reali

La risposta breve: security observability non è una categoria di prodotto con confini netti come il SIEM. Il SIEM ha una definizione formale e un mestiere preciso: raccogliere log, normalizzarli, correlarli con regole, generare alert e conservarli. La security observability descrive piuttosto un modo di lavorare sui dati di sicurezza, con schemi più larghi e ricerca esplorativa. Le due cose si sovrappongono, e sulle piattaforme moderne convivono nello stesso prodotto.

La domanda di chi ha già un SIEM, o lo sta scegliendo, è sempre la stessa: è una cosa nuova, un modo diverso di chiamare quello che ho già, o un pezzo in più da mettere a budget? Per rispondere onestamente bisogna dire, punto per punto, quando una differenza è di architettura e quando è di posizionamento commerciale.

Cosa fa un SIEM e da quale problema nasce

Il glossario del NIST definisce il software SIEM, riprendendo la SP 800-92, come a program that provides centralized logging capabilities for a variety of log types. Definizione asciutta, ma dice la cosa giusta: al centro c'è la centralizzazione dei log.

Il problema da cui nasce è concreto. Un attacco serio quasi mai tocca un solo sistema: un accesso anomalo, un movimento laterale, un download insolito e un tentativo di esfiltrazione, presi uno per uno, sembrano rumore. Serve un posto in cui quegli eventi arrivano tutti, un formato comune che li renda confrontabili e un motore che li metta in fila. La guida di riferimento è cos'è un SIEM e come funziona.

Il mestiere del SIEM, nelle quattro cose che un responsabile compra davvero:

• Raccolta e normalizzazione dei log di endpoint, rete, cloud, identità e applicazioni in un modello dati comune.
• Correlazione su regole: schemi noti di attacco descritti in un linguaggio di detection e valutati in continuo.
• Alerting: quando una regola scatta nasce un caso su cui qualcuno deve lavorare.
• Conservazione dei dati per le indagini a posteriori e per dimostrare la conformità a chi la chiede.

Un dettaglio che spiega molto: quella SP 800-92 è del settembre 2006, e la sua revisione (SP 800-92 Rev. 1) è uscita come bozza pubblica l'11 ottobre 2023 e resta allo stato di bozza. Il vocabolario formale si muove più lentamente del mercato che lo vende.

Cosa intende il mercato per observability

Il termine non nasce nella sicurezza, nasce nell'ingegneria del software. La definizione di riferimento è quella della documentazione di OpenTelemetry, il progetto open source che standardizza la telemetria: observability lets you understand a system from the outside by letting you ask questions about that system without knowing its inner workings. Lo scopo dichiarato è gestire i problemi nuovi, quelli che la stessa pagina chiama unknown unknowns.

I tre segnali

Nell'accezione di ingegneria la telemetria è fatta di tre segnali:

• Log: messaggi con marca temporale emessi da un servizio o da un componente.
• Metriche: aggregazioni nel tempo di dati numerici su infrastruttura o applicazione.
• Tracce: il percorso di una singola richiesta attraverso più servizi.

Cosa cambia applicandola alla sicurezza

Trasferendo l'idea alla sicurezza, la promessa diventa: non solo far scattare le regole che hai scritto, ma poter fare domande che non avevi previsto, su dati che non avevi preparato per quella domanda.

Qui però va detta la prima cosa scomoda. Il SIEM ha una voce nel glossario del NIST, la security observability no: sul glossario CSRC la pagina del termine observability risponde 404, e non ne esiste una nemmeno per security observability, mentre lo stesso glossario ha da anni una voce per il concetto più vicino, l'Information Security Continuous Monitoring, definito nella SP 800-137 come mantenere una consapevolezza continua di sicurezza, vulnerabilità e minacce a supporto delle decisioni di gestione del rischio. Nel vocabolario formale del NIST non è quindi una categoria definita: è soprattutto un termine di mercato, e conviene saperlo quando due offerte usano la stessa parola per cose diverse.

Le quattro differenze di cui si discute, e quali reggono

1. Il modello dei dati e lo schema

È la differenza architetturale più reale. Un SIEM normalizza su uno schema fisso: lo Unified Data Model di Google SecOps, per fare un esempio pubblico e verificabile, prevede campi obbligatori e un elenco chiuso di tipi di evento, dai login ai processi al traffico di rete, e le regole in YARA-L lavorano su quei campi. Questo rende le detection veloci, ripetibili e confrontabili fra clienti diversi.

Il rovescio è che lo schema decide cosa puoi chiedere: se un campo non è previsto dal parser, quel dettaglio non è interrogabile finché qualcuno non estende il parser. L'approccio observability parte dall'altro lato: schema largo, si conserva quello che il sistema emette e si decide dopo cosa è interessante. Si paga in prestazioni e disciplina, si guadagna in domande possibili.

2. Il costo e il volume

Nell'ingegneria il modo standard di tenere sotto controllo il costo della telemetria è campionare. La documentazione di OpenTelemetry lo dice esplicitamente: sampling is one of the most effective ways to reduce the costs of observability without losing visibility, e aggiunge che per sistemi ad alto volume un tasso dell'1% o inferiore rappresenta spesso in modo accurato il restante 99%.

Sulla sicurezza il ragionamento regge solo in parte. Una traccia su cento basta a dirti che le latenze crescono, non a ricostruire cosa ha fatto un account compromesso in tre settimane. Sui dati che servono a indagare e a rispondere a un'autorità la completezza non è un lusso. Per questo sul SIEM il dibattito sul costo riguarda cosa raccogliere e per quanto conservarlo, non quanto campionare.

3. Il tempo per rispondere a una domanda non prevista

È la differenza che si sente sulla propria pelle, ed è misurabile senza discussioni tassonomiche: quanto ci metti, oggi, a rispondere a una domanda che nessuna regola aveva previsto.

Non è teoria. Il D.Lgs. 138/2024, che recepisce NIS2 in Italia, all'articolo 25 comma 5 chiede ai soggetti essenziali e importanti una pre-notifica al CSIRT Italia entro 24 ore dalla conoscenza dell'incidente significativo, una notifica entro 72 ore con una valutazione iniziale di gravità e impatto e, ove disponibili, gli indicatori di compromissione, e una relazione finale entro un mese dalla notifica delle 72 ore, che includa il tipo di minaccia o la causa originale (root cause) che ha probabilmente innescato l'incidente. Nessuno dei tre passaggi è coperto da una regola di correlazione: sono tre indagini con scadenza. Se rispondere a una domanda nuova richiede di aprire un ticket e aspettare due giorni, il problema non è il nome della categoria di prodotto: è che i dati non sono cercabili da chi deve cercarli.

4. Rilevare ciò che nessuna regola descrive

Qui va detta la seconda cosa scomoda, perché è il punto in cui il marketing lavora di più. Il claim implicito di molte offerte è: le regole vedono solo quello che già conosci, noi vediamo il resto.

Metà è vera: una detection scritta a regole copre schemi noti, e un attaccante che non assomiglia a nessuno schema noto non la fa scattare. L'altra metà è posizionamento. L'analisi comportamentale non è una novità dell'observability: è una capacità documentata delle piattaforme SIEM sotto il nome di UEBA, e la documentazione di Microsoft Sentinel, per fare un esempio verificabile, la descrive come costruzione di profili comportamentali per utenti, host, indirizzi IP e applicazioni con punteggi di rischio sulle anomalie. In ogni caso qualcuno deve formulare l'ipotesi e decidere se è un attacco o un cambio di abitudini. La caccia alle minacce è un'attività umana assistita dallo strumento, non una proprietà del formato dei dati.

Dove le due cose convergono

La convergenza non è un'opinione nostra, è documentata dalle parti in causa.

• Il 17 aprile 2023 OpenTelemetry ha annunciato la convergenza fra Elastic Common Schema e le proprie semantic conventions in un unico schema aperto. Il post parla apertamente di convergence of observability and security in this space e ricorda che ECS copre anche i campi del dominio della sicurezza. Nella documentazione Elastic, ECS è descritto come una specifica che definisce un insieme comune di campi per i dati di evento, log e metriche compresi.
• Sul lato piattaforma, la documentazione di Google SecOps elenca fra i metodi di raccolta forwarder, parser, connettori, webhook e OpenTelemetry collectors: lo strumento nato per la telemetria applicativa è oggi una delle vie di ingresso dei dati in una piattaforma di security operations, descritta dalla stessa pagina come un servizio cloud per conservare, analizzare e cercare grandi volumi di telemetria di sicurezza e di rete (cos'è Google SecOps).

Conclusione onesta: sulle piattaforme moderne il confine fra SIEM e observability è spesso una divisione di listino più che di motore. Lo stesso archivio, gli stessi dati normalizzati, due modi di interrogarli e due nomi commerciali. Non vuol dire che tutte le offerte siano equivalenti, vuol dire che la domanda su quale delle due comprare è quasi sempre mal posta.

Come si decide, in pratica

Invece di scegliere fra due etichette, conviene rispondere a cinque domande sulla propria situazione, con i dati che hai già.

1. Quante domande nuove ti arrivano al mese? Se il lavoro è quasi tutto sugli alert delle regole, un motore di correlazione calibrato ti basta. Se ogni settimana qualcuno chiede cosa ha fatto un certo account in aprile, il costo lo stai già pagando in tempo di ricerca.
2. Quanto tempo passa fra la domanda e la risposta? Misuralo su tre casi reali dell'ultimo trimestre, non a sensazione. È il numero che decide.
3. Quali sorgenti non stai raccogliendo, e perché? Se la ragione è il costo per gigabyte, il problema è il modello di prezzo dei dati, non la categoria di prodotto: il confronto è nella guida alla scelta di un software SIEM.
4. Cosa devi poter dimostrare, e con che finestra? Scadenze di notifica e retention di settore fissano un minimo che l'architettura non negozia.
5. Chi guarda i dati alle tre di notte? Se la risposta è nessuno, le prime quattro domande cambiano poco.

Il punto che vale più di tutti

Si può migrare da un motore di correlazione a uno schema largo, raddoppiare la retention, aggiungere un prodotto con la parola observability sulla copertina. Se nessuno legge quei dati e nessuno indaga, cambia lo strumento e non cambia il risultato.

È la stessa conclusione del SIEM: lo strumento produce segnali, il presidio produce esiti. Il SOC è la parte che trasforma una domanda in una risposta, di giorno e di notte. Il vantaggio reale di una piattaforma che tiene insieme correlazione e ricerca esplorativa è che l'analista perde meno tempo a cambiare strumento a metà di un'indagine, e questo accorcia i tempi sulle scadenze normative. Ma è l'analista a fare l'indagine.

AmagisTech costruisce security operations per il mid-market italiano partendo da qui, non dalla categoria di prodotto: quali domande devi poter fare, in quanto tempo, e chi le fa. Per capire a che punto sei, parti dai nostri servizi di observability e SecOps.

In sintesi: il SIEM è una categoria con una definizione formale, la security observability è in buona parte un termine di mercato che descrive un modo di interrogare i dati. Le differenze reali sono due, lo schema e il campionamento. Il resto, compresa la separazione fra i due prodotti in molti listini, è posizionamento, e la variabile che decide resta chi guarda.