Ridurre il Tempo di Rilevamento delle Violazioni: Disponibilità dei Dati di Log

Ciao di nuovo! Nell’ articolo precedente, abbiamo già stabilito che molte cose possono sfuggire di mano quando si tratta di costruire un SOC virtuale o su larga scala, soprattutto quando si tratta di rendere operativo il SIEM come tecnologia centrale di qualsiasi SOC. Abbiamo anche stabilito che l’automazione è la strada da seguire se si vuole stare al passo con le minacce moderne e il sovraccarico prodotto dalle tecnologie SIEM & SOC. Oggi iniziamo ad analizzare singolarmente ogni componente di implementazione e operazioni del SIEM, il primo che viene in mente è la disponibilità dei dati. Ci sono molti fattori che influenzano il tempo di rilevamento delle violazioni e, a partire dal 2015, è ancora superiore alla media di 200 giorni, ma questo non perché il SIEM sia una tecnologia scelta per il rilevamento delle violazioni. Un SIEM può fornire solo l’output basato sugli input che riceve, e se qualcosa manca in input, non dovremmo aspettarci che l’output sia completo, utilizzabile e a volte non avremo alcun output.È davvero colpa del SIEM che mancano log (e incidenti)? Bene, questo dipende di nuovo da molti fattori e per chiarire questa confusione e mantenere il SIEM operativamente continuo, la persona responsabile della sua amministrazione/manutenzione (la tua azienda ne ha uno, giusto?) deve avere abbastanza informazioni in qualsiasi momento per rispondere a queste due domande: “Tutti i log dati rientranti nell’ambito sono raccolti?” e se la risposta è NO “Il problema è sul lato SIEM o al di fuori di esso?”. Se la risposta alla prima domanda è NO, siate sicuri che state perdendo cose importanti che hanno un impatto diretto sul tempo di rilevamento dell’incidente e sulla precisione. E la verità è che nessuna soluzione SIEM risponde semplicemente a questa domanda di default – è sempre uno sforzo manuale rispondere a questa domanda.Hai mai visto un SIEM che dice “La disponibilità dei dati log di rete è del 85%”? Io no. Tuttavia, abbiamo ancora una seconda domanda a cui ovviamente non viene risposto dal sistema stesso, poiché non può rispondere alla prima. Ma, non tutto è perduto e le risposte ci sono se si fanno abbastanza ricerche o si sono dedicati abbastanza tempo e sforzi per cercarle manualmente.Consideriamo alcuni esempi basati su come si raccolgono i dati di log e iniziamo con il meccanismo di raccolta dei log più comune – syslog. È improbabile che si possa nominare un’implementazione SIEM che non utilizzi affatto syslog. Ci sono molti modi in cui i dati possono essere persi con syslog: un daemon su metodo di raccolta pipe perde dati quando il componente di raccolta viene fermato; un protocollo syslog UDP (predefinito) non garantisce la consegna dei pacchetti, l’alto volume di traffico syslog (sia UDP che TCP) può essere compromesso da limiti di dimensione del buffer e limitazioni di larghezza di banda e persino dalle specifiche di elaborazione del tasso di pacchetti di un concreto NIC. Anche nel caso di lettura dei dati di log da un file si deve considerare la rotazione e l’integrità del file. La diagnostica di questi problemi è sempre un compito manuale di routine che coinvolge la lettura dei log diagnostici dei componenti SIEM stessi. Se ha dati diagnostici per iniziare! Anche i dati diagnostici più brutti sono meglio di nessun dato diagnostico e una scusa economica di “oh, il nostro SIEM è così magico che non ha errori!”. Successivamente, saremmo occupati a costruire (o riutilizzare?) contenuti di correlazione che basano le quantità di flusso dei log e le deviazioni (Qualcuno è davvero soddisfatto dei risultati di un tale contenuto? E delle risorse che consuma?), eseguendo TCPdump per controllare i tassi di perdita dei pacchetti, monitorando la disponibilità dei componenti attraverso fonti esterne… Aspetta, penso che abbiamo ideato almeno 3 strumenti aggiuntivi che devono essere aggiunti al SIEM per monitorarsi, solo per rispondere alla semplice domanda “Qual è il % di disponibilità dei miei dati di log di rete?”. Se parliamo di tentativi concreti per rendere questo automatico, diciamo, Splunk su Splunk, sono davvero efficienti? Quanto costa in più di licenza si deve aggiungere per essere in grado di autodiagnosticare la piattaforma SIEM/Gestione dei Log e quanto sovraccarico di prestazioni produce questa app più popolare?..

Okay, mettiamo da parte syslog e Splunk per qualche minuto e pensiamo alla seconda fonte di log più popolare – Microsoft Windows Event Log. Per mantenere le questioni brevi: rotazione dei log, larghezza di banda della rete, errori di autenticazione/blocchi password, instabilità di WMI e JCIFS, alto carico dei server Windows occupati (audit file, Active Directory ecc.). Monitorare ciò richiederebbe di nuovo un intero set di strumenti e tali strumenti saranno diversi se confrontati con gli strumenti di monitoraggio syslog! Possiamo continuare con un lungo elenco che include database, firewall/ngfw/ips/ngips/utm (ciao OPSEC & SDEE) e scopriremo ancora più cose che accadono al di fuori del SIEM, che il SIEM non influisce ma deve conoscere(!) e deve fornire queste informazioni rapidamente e accuratamente all’amministratore. Tuttavia, per chi legge fino a qui, ci sono buone notizie, poiché il SIEM (o la maggior parte dei SIEM) ha log diagnostici leggibili (quasi). Quei file diagnostici difficili da trovare, chiamate API nascoste o tracce di stack java multilinea contengono bit e byte di informazioni che potrebbero fornire risposte a molti dei problemi sollevati sopra. E combinando questi insieme e applicando metriche di profilazione significative possiamo rispondere a quelle due semplici domande che significano una differenza totale tra sapere che la tua piattaforma critica di rilevamento della sicurezza missione funziona come previsto o ignorare il problema/semi-risolverlo gettando più FTE sul problema. L’automazione è qui per tutti coloro che vogliono assicurarsi che i loro dati di log siano disponibili come previsto nel progetto, richiesto dall’organizzazione/cliente e che ottengano un adeguato ritorno sull’investimento SIEM. Spero che questo vi lasci con qualche spunto di riflessione. Rimanete sintonizzati!

P.S. In caso tu sia uno degli esperti di HPE ArcSight, ci sono altre buone notizie! Come parte di un’iniziativa globale per far sì che le piattaforme SIEM forniscano valore e risparmiando tempo agli esperti di SIEM in tutto il mondo, SOC Prime fornisce un servizio gratuito di controllo istantaneo della salute del SIEM online, che può elaborare file agent.log e fornirvi le 5 questioni critiche principali e le soluzioni a queste in meno di 5 minuti. Hai un agent.log? Lancialo qui e vedi tu stesso!