domanda di pre-filtraggio log SIEM

4

Come tutti sanno, ogni azienda vuole risparmiare più denaro possibile. Sono stato incaricato di pre-filtrare i log su messaggi di stato / salute meno importanti prima che arrivassero al SIEM.

  1. Qualcuno vede i rischi che comporta il pre-filtro prima di partire a SIEM?
  2. Perché qualcuno non dovrebbe farlo e o c'è un vantaggio nel farlo se hai le risorse?
  3. Risparmiare denaro su base di log è la pena pre-filtrare prima di esso arriva al SIEM?
posta Jon_Little-Sec Engineer 22.08.2013 - 20:10
fonte

2 risposte

8

Ci sono due motivi per cui il pre-filtro è fatto: per risparmiare sulla velocità EPS (eventi al secondo) e per ridurre il rumore. Ogni tecnologia SIEM ha una capacità di analisi EPS massima, limitata dall'hardware o dalla licenza del software. Quando gli eventi superano questa limitazione, il server SIEM inizia a eliminare i pacchetti. Questo è il motivo per cui vorresti solo introdurre solo quegli eventi che hanno implicazioni di sicurezza significative.
Ma ancora più importante dell'EPS è ridurre gli eventi in modo che i tuoi analisti possano analizzare manualmente quegli eventi. Sebbene la tecnologia SIEM possa automatizzare molte attività di correlazione degli eventi, inizialmente è necessario che un analista analizzi manualmente ciascun registro o evento di traffico ricevuti per determinare se sia positivo o falso positivo. Quando si sommerge il sistema con un sacco di eventi rumorosi che non hanno implicazioni per la sicurezza, non solo si sta sovraccaricando le risorse hardware e software del sistema ma si sta addirittura sovraccaricando l'analista nell'analizzare tali eventi.
Sulla base della mia esperienza, è necessario capire che una soluzione SIEM efficace è quella che sta analizzando solo gli eventi di sicurezza. Molte volte le persone vogliono lasciare che il SIEM analizzi e co-relazionano anche molti eventi di non sicurezza. A volte ciò potrebbe essere utile come correlare le informazioni sullo stato del sistema con i registri di traffico ricevuti in caso di attacchi denial of service, tuttavia, nella maggior parte dei casi, pre-filtrare tutti i log e gli eventi non di sicurezza e inoltrare solo i registri rilevanti a il tuo SIEM renderà il sistema e l'analista SIEM più efficienti.

    
risposta data 22.08.2013 - 21:00
fonte
1

Lavoro per la società che sta sviluppando la SIEM soluzione per gli ultimi 5 anni, quindi devo costantemente parlare con e clienti esistenti, aiutandoli a scegliere il modo migliore per integrare ciò che offriamo.

Ciò che mi viene in mente riguardo a SIEM e al pre-filtraggio è se è necessario mantenere intatti i registri quando si accede al sistema a causa delle varie normative nazionali. Questo potrebbe o potrebbe non essere importante per la tua azienda.

In secondo luogo, se il SIEM offre un piano $$ che si concentra sui dati archiviati e non sui dati trasferiti, è possibile filtrare ciò che effettivamente entra nell'archiviazione (livello di conservazione, parte di preindicizzazione) in modo da non spendere troppo spazio di archiviazione e non uccidere SIEM avvisando con troppi dati spazzatura. La configurazione di ciò che introduce SIEM e ciò che viene scartato a livello di SIEM e non a livello di OS guadagna un maggiore controllo su ciò che accade se qualcuno esce, cambia sistema operativo o simili. Guarda le regole SIEM come documentazione per la tua infrastruttura. Se è tutto in un posto, è più semplice da guardare se è distribuito in luoghi non standard.

TLDR Raccoglierei tutto e fare poche regole nel livello di conservazione in modo che i dati non entrino nel livello di indicizzazione (avviso, correlazione ecc.). Se ci sono dei complimenti normativi da seguire, vorrei partire così com'è.

    
risposta data 23.08.2013 - 12:50
fonte

Leggi altre domande sui tag