In un mondo con esigenze di sicurezza sempre più complesse, come assicurarci che quanto facciamo ripaghi le aspettative? Vediamo un altro metodo IP Fabric per la Network Security Assurance che, oltre a renderti più sicuro, può farti risparmiare tempo e denaro. (Se te la sei persa, leggi qui la 1° parte dell’articolo.)
Impostare la raccolta dei log e dei servizi SIEM può apparire semplice, ma chiunque abbia dovuto farlo sa che non lo è. Oltre alle opportune decisioni tecniche sui dispositivi da cui ottenere i log, occorre ragionare a livello economico e capire quanti dispositivi possiamo raccogliere e per quanto tempo archiviare i dati. Per natura i SIEM sono sistemi high touch, richiedono monitoraggio, assistenza e alimentazione costanti. Per esempio, l’aggiunta di nuovi dispositivi è possibile unicamente se sono stati configurati correttamente cosi da poter inviare i log e via dicendo.
In passato, almeno riguardo la rete e i dispositivi di sicurezza, il dimensionamento SIEM è stato una combinazione di tre aspetti: congetture, buon senso e revisioni manuali fatte ad arte. Quando sono stato coinvolto nella progettazione SIEM, ho sempre suggerito di iniziare con switch core, border router, firewall load balancer, per poi passare ad altri dispositivi fondamentali. Ritengo fosse il consiglio migliore nella maggior parte dei casi, per lo meno un buon punto di partenza, ma è facile accorgersi di quanto fosse generico. Questo perché non possedevo una visione globale della rete e dei flussi di traffico associati. Qualora l’avessi avuta, sarei stato in grado di vedere a colpo d’occhio tutti i colli di bottiglia, i punti di distribuzione chiave e altri dati, che mi avrebbero permesso di:
1) Organizzare per priorità i dispositivi che richiedevano la raccolta e la correlazione dei log;
2) Capire rapidamente quali dispositivi non offrivano un valore sufficiente da spendere risorse nel logging.
Quando ci sono di mezzo le finanze, decidere cosa non va raccolto è importante quasi quanto ciò che deve esserlo.
La maggior parte delle grandi aziende vittime di attacchi informatici possiedono servizi SIEM, ma molte di esse nemmeno sanno di aver subito una violazione. Sul fatto che la maggior parte delle aziende possa o no raggiungere uno stato di progettazione SIEM accettabile, potremmo discutere a lungo. Personalmente ritengo che molti vi riescano almeno una volta, ma poi con che cadenza quel progetto vincente viene aggiornato e in che modo? Le reti non sono statiche, non lo sono mai state e l’avvento di cloud e DevOps le ha rese ancora più fluide. Se da una parte cloud e DevOps hanno aumentato l’agilità delle aziende con implementazioni semplificate delle reti, dall’altra hanno comportato una maggiore complessità di gestione, con l’inserimento di nuovi elementi in gioco. Da qui la domanda: come può un’organizzazione garantire che una soluzione di logging (che sia Splunk, Elastic, IBM, Sumo Logic, ecc.) si mantenga efficace dopo l’installazione iniziale?
Prima di rispondere, vediamo gli altri problemi che riscontriamo di frequente con i SIEM. Supponendo di avere tutti i dispositivi giusti e di poter aggiornare gli operatori affinché aggiungano i dispositivi idonei al momento opportuno, come assicurarci che tali dispositivi siano sempre configurati correttamente per inoltrare i log? Cosa accade quando il dispositivo viene aggiornato o modificato, o quando il produttore cambia qualcosa? Come possiamo avere un quadro chiaro, senza ricorrere a revisioni manuali della configurazione, qualora qualcosa non funzioni più come previsto? Come possiamo essere avvisati del cambiamento?
La risposta è uno strumento che esegua la Network discovery automatica e che crei snapshot aggiornati più volte al giorno senza impattare la rete, quindi traduca tale discovery e le informazioni derivate dagli snapshot in un riferimento visivo (mappa della rete logica sovrapposta a una mappa della rete fisica). Questo stesso strumento deve quindi eseguire le regole di assurance, alla pari del dispositivo che agisce come router principale (il dispositivo che abbiamo deciso debba fare il log), e inviare i suoi registri al SIEM se non c’è stato un alert per la review.
Ho lavorato in diversi ambienti importanti, in cui si sono spesi milioni di dollari per il SIEM. La lacuna più grande era una assurance platform che facilitasse la configurazione iniziale e la gestione successiva.
Bene, è tutto per questo post: tornerò tra poche settimane con la terza ed ultima puntata su come utilizzare una piattaforma di Network Security Assurance e risolvere i problemi del mondo reale.
