Raccolta dei dati del dispositivo di rete ai fini del rilevamento della sicurezza

2

Ho finalmente ottenuto il team di networking per iniziare a condividere i dati sui dispositivi che gestiscono (router, firewall, VPN, NAC, ecc.), così possiamo ottenere una visione più approfondita della nostra rete e concentrarci maggiormente sul rilevamento.

Nel migliore dei modi non creare una manichetta antincendio di tronchi scartati. Voglio affrontarlo nel modo più efficiente possibile.

Volevo chiedere consiglio alla comunità perché questo è un argomento nuovo per me.

Siamo in procinto di ottenere un SIEM, e il mio primo pensiero è di lavorare con il team di networking per determinare quale syslog da detti dispositivi di rete sopra (inviato al SIEM) sarebbe utile per le nostre esigenze.

Mi stavo chiedendo come si avvicinano tutti gli altri in quest'area? È normale che il personale di sicurezza abbia accesso diretto a firewall, interfacce NAC, ecc.? o è un output syslog per ciò che in realtà vogliamo più appropriato?

    
posta estudiante 23.10.2015 - 17:15
fonte

3 risposte

2

Quando si avvia un progetto SEIM, un approccio graduale alla gestione degli eventi di sicurezza è un buon approccio per l'inventario di EG e la priorità dell'infrastruttura e la valutazione di ogni dispositivo in base al suo impatto / esposizione sulla sicurezza. Ad esempio, otterrete informazioni sugli eventi di sicurezza più dettagliate da un firewall piuttosto che da un router. Allo stesso modo con i registri di accesso Web, i registri degli eventi a livello di sistema operativo e HIDS.

Is it normal for security guys to have direct access to firewalls, nac interfaces, etc

Dipende dall'organizzazione e dai processi di sicurezza. La configurazione del firewall può essere lasciata agli amministratori di rete, mentre le operazioni di sicurezza potrebbero essere responsabili del monitoraggio dei registri e delle modifiche ai criteri di controllo, pur non avendo accesso diretto alla loro configurazione.

is syslog output for what we actually want more appropriate?

In questa fase del processo, i registri yes rappresentano l'origine dati principale per l'implementazione SEIM. La sfida più grande nell'aggregazione dei log da utilizzare in SEIM è il filtraggio del rumore e la concentrazione sulle autentiche firme degli eventi di sicurezza, al fine di eliminare i falsi positivi ed evitare l'effetto "firehose" che citi.

Come suggerimento, in questa fase, considera i servizi di aggregazione dei log come PaperTrail e Splunk. È possibile visualizzare rapidamente tutti gli eventi e i formati dei registri in tempo reale e iniziare a definire i filtri e in generale capire quali dati di registro saranno fondamentali per l'implementazione di SEIM.

    
risposta data 23.10.2015 - 17:47
fonte
1

L'architettura di sicurezza è essenziale in questo scenario. Come ha detto Rodrigo, dovresti dare la priorità. Soprattutto quando c'è un budget in gioco. Identifica i punti di ingresso / uscita, identifica l'infrastruttura critica che devi monitorare senza problemi e prova a distribuire i sensori intorno a questo.

Devi anche tenere a mente la conservazione dei dati. In un mondo perfetto, registreremmo la cattura di pacchetti completi tutto il giorno ogni giorno, ma in realtà, la maggior parte delle reti genera troppo traffico per mantenere l'acquisizione completa dei pacchetti per una quantità di tempo decente. Prendi in considerazione soluzioni come NetFlow v5, che è molto più semplice per l'archiviazione dei dati e fornisce ancora i dati necessari per correlare i registri e indagare sugli incidenti.

Inoltre, il killer, identifica dove hai NAT per assicurarti di non perdere metà dei log su NAT. Ad esempio, se si dispone di un sensore su entrambi i lati di un servizio di bilanciamento del carico che non è configurato con X-Forwarded-For o Enhanced Logging, gli indirizzi IP di origine saranno persi e le indagini diventeranno dolorose.

Per quanto riguarda l'accesso ai registri, personalmente credo che gli analisti della sicurezza della rete, in particolare, dovrebbero avere accesso a tutti i registri disponibili per aiutare a correlare i registri da varie fonti e accelerare le indagini. Non necessariamente l'accesso amministratore, ma l'accesso in sola lettura sarebbe sufficiente. Quindi dovresti avere i log dai tuoi sensori, firewall, syslog dai router / load balancer ecc. Se hai accesso solo ai log originati dai sensori, ancora una volta, la vita può diventare dura.

Il punto finale è identificare tutte le fonti log, scegliere un SIEM adatto e centralizzare / inoltrare tutti i registri al SIEM. Saltare su dispositivi diversi per cercare un indirizzo IP specifico tra X e Y date è noioso e terribilmente dispendioso in termini di tempo quando ci sono un sacco di potenti soluzioni SIEM là fuori.

Quando si arriva a questo, hai detto che non volevi creare una "manichetta antincendio dei log scartati", personalmente ritengo che quanto sopra sia il modo migliore per farlo. La riprogettazione dell'infrastruttura di rete dal punto di vista della sicurezza richiederà molto lavoro, ma alla fine lavorerai con ciò di cui hai bisogno e, si spera, il rumore sarà minimo.

Ran poco tempo, scuse.

    
risposta data 23.10.2015 - 18:01
fonte
1

La maggior parte dei dispositivi di rete può essere configurata per inviare solo un tipo specifico di log a un Syslog. Inoltre, non penso che tu stia cercando le informazioni dai protocolli di routing e switching esistenti in L2 e L3. Pertanto, ad eccezione dei registri di determinati dispositivi di sicurezza e di determinati router chiave, non vedo il valore nella raccolta dei registri da tutti i dispositivi di rete.

Il mio consiglio è di iniziare a spedire prima i log IDS e poi identificare gradualmente le altre aree / protocolli / dispositivi chiave e quindi spedire i log da loro.

    
risposta data 23.10.2015 - 18:02
fonte

Leggi altre domande sui tag