CISO della Borsa di Tel Aviv: fare un uso migliore del SIEM

CISO della Borsa di Tel Aviv: fare un uso migliore del SIEM

Timestamp: 18 agosto 2023 2:18

Per Gil Shua, ottenere il massimo dal sistema SIEM (Security Information Event Management) per la Borsa di Tel Aviv significa ottenere il giusto rapporto segnale-rumore. Quello e scrivere le regole giuste.

Il rapporto segnale-rumore, come sa ogni ingegnere di radiofrequenza, si riduce alla quantità di contenuto effettivo (segnale) rispetto all'elettricità statica e ad altri disturbi sonori (rumore). Per Shua, l'obiettivo è ridurre al minimo la quantità di rumore inviato al SIEM a favore di contenuti fruibili. Sta cercando qualcosa che lo faccia alzare dalla scrivania con la consapevolezza: “Abbiamo un problema; abbiamo qualcosa che vogliamo affrontare ora e risolverlo.

Shua ha lavorato in varie posizioni nel settore della sicurezza presso la Borsa di Tel Aviv (TASE) per più di un decennio ed è stato nominato CISO nel 2022. Durante quel periodo, afferma che è stata una "caccia costante alle risorse di dati" per garantire che il segnale- il rapporto rumore-rumore si inclina a favore dei dati del segnale per massimizzare le capacità e i vantaggi del SIEM dell'exchange.

CISO della Borsa di Tel Aviv Gil Shua

CISO della Borsa di Tel Aviv Gil Shua. Fonte: Gil Shua, Borsa di Tel Aviv

Filtrare il rumore

Shua e il suo team hanno il loro bel da fare poiché con la maggior parte dei SIEM "si vede molto rumore e non molto segnale". Ciò porta a falsi positivi e configurazioni errate che, a loro volta, creano lavoro extra per il team SOC, riducono la produttività e costituiscono un ostacolo al cercando di far funzionare un SIEM.

Per ridurre al minimo questo problema, Shua afferma che il team SOC può scrivere regole su come il SIEM gestisce i dati in entrata, ma la creazione di tali regole richiede anche tempo prezioso per il team SOC.

Ma scrivere regole di correlazione SIEM è relativamente semplice se la soluzione SIEM dispone già di regole e analisi dei log predefinite per l'applicazione di reporting, afferma Shua. Ma prima che le regole possano essere scritte, il team SOC deve: 

  • Individua la struttura dei dati e identifica i campi pertinenti necessari per la regola.
  • Comprendere la logica dei sistemi di reporting poiché potrebbero avere i propri standard di registro.
  • Crea una correlazione esatta delle regole e analizza le eccezioni.
  • Eseguire controlli e test di qualità.

Queste azioni possono richiedere alcune ore ciascuna, ma se sono più complesse, possono richiedere giorni per essere completate, aggiunge Shua.

“Quando crei un SIEM, hai due preoccupazioni. La prima è "Ho norme che mi proteggono da attacchi rilevanti... sono protetto da norme efficaci?" La seconda cosa è: 'Ricevo dai sistemi di segnalazione le informazioni che faranno scattare queste regole?'."

La recente aggiunta della piattaforma CardinalOps ha migliorato Splunk Enterprise al TASE; Shua afferma che il processo di scrittura delle regole è stato notevolmente ridotto, con 85 regole prodotte nei pochi mesi in cui questa particolare tecnologia è stata utilizzata. "Il team è più concentrato sull'implementazione delle regole e sul loro test piuttosto che sulla loro scrittura, che era il processo che richiedeva più tempo nel collegamento", aggiunge.

Quindi i SIEM valgono il tempo e il denaro spesi per la correlazione e la scrittura delle regole? Shua ammette che mantenere un SIEM è un compito impegnativo, poiché sono necessari aggiornamenti e modifiche costanti. Nonostante tutti gli sforzi, alcuni attacchi potrebbero passare inosservati a causa della mancanza di visibilità o di regole di corrispondenza.

"Mi aspetto che le soluzioni future adottino capacità di automazione per la creazione e la risposta di regole autonome, pronte all'uso", afferma Shua. 

E poiché i SIEM traggono dati da molte fonti, devono diventare più efficienti nell'elaborazione, analisi e archiviazione dei dati in formati diversi. "È necessario apportare modifiche per mantenerlo", afferma Shua, aggiungendo che una gestione impropria delle modifiche significa che è probabile che un'organizzazione perda alcuni eventi di sicurezza.

Timestamp:

Di più da Lettura oscura