Quando si parla di monitoraggio della sicurezza di una rete aziendale interna o di un ente, molti associano questo termine al controllo delle perdite di informazioni e all'implementazione di soluzioni DLP. Ma se proviamo a chiarire la questione e chiediamo come si rilevano gli attacchi all'interno della rete, la risposta sarà, di solito, un riferimento ai sistemi di rilevamento delle intrusioni (intrusion detection systems, IDS). Ciò che era l'unica opzione circa 10-20 anni fa, oggi diventa un anacronismo. Esiste un'opzione più efficace, e in alcuni casi anche l'unica possibile, per il monitoraggio della rete interna: utilizzare i protocolli di flow, inizialmente concepiti per la risoluzione dei problemi di rete (troubleshooting), ma che nel tempo si sono trasformati in uno strumento di sicurezza molto interessante. In questo articolo parleremo dei diversi protocolli di flow, di quali siano più utili per rilevare attacchi di rete, di dove sia meglio implementare il monitoraggio del flow, di cosa prestare attenzione durante la realizzazione di questa architettura e persino di come “alzarla” su hardware domestico.
Non mi fermerò sulla questione “Perché è necessario il monitoraggio della sicurezza delle infrastrutture interne?”. La risposta sembra piuttosto ovvia. Ma se comunque desiderate confermare ancora una volta che oggi non si può fare a meno di questo, un breve video che spiega 17 modi in cui si può penetrare in una rete aziendale protetta da un firewall. Quindi consideriamo che comprendiamo che il monitoraggio interno è necessario e rimane solo da capire come organizzarlo.
Indicherei tre fonti chiave di dati per il monitoraggio dell'infrastruttura a livello di rete:
- il traffico “grezzo”, che catturiamo e inviamo per l'analisi a un certo sistema di analisi,
- eventi provenienti dai dispositivi di rete attraverso i quali passa il traffico,
- informazioni sul traffico ottenute tramite uno dei protocolli di flow.
Catturare il traffico grezzo è l'opzione più popolare tra gli specialisti della sicurezza, poiché è storicamente la più antica. I normali sistemi di rilevamento intrusioni (il primo sistema commerciale di rilevamento delle intrusioni è stato NetRanger dell'azienda Wheel Group, acquisito da Cisco nel 1998) si occupavano appunto della cattura dei pacchetti (e successivamente delle sessioni), nei quali si cercavano specifiche firme (“regole decisive” nella terminologia del FSTEK), che segnalavano attacchi. Naturalmente, è possibile analizzare il traffico grezzo non solo tramite IDS, ma anche attraverso altri strumenti (ad esempio, Wireshark, tcpdump o la funzionalità NBAR2 in Cisco IOS), ma di solito mancano di una base di conoscenze che differenzia uno strumento di sicurezza informatica da un normale strumento IT.
Quindi, i sistemi di rilevamento delle intrusioni. Il metodo più antico e popolare per rilevare le intrusioni di rete, che svolge adeguatamente il suo compito al perimetro (indipendentemente che sia aziendale, di un centro dati, di un segmento, ecc.), ma che si trova in difficoltà nelle reti moderne commutate e definite via software. Nel caso di una rete basata su normali switch, l'infrastruttura dei sensori di rilevamento delle intrusioni diventa troppo grande: dovrai installare un sensore per ciascuna connessione a un nodo, per cui vuoi monitorare gli attacchi. Ogni produttore sarà felice di venderti centinaia e migliaia di sensori, ma penso che il tuo budget non reggerebbe tali spese. Posso dire che anche in Cisco (dove sviluppiamo NGIPS) non siamo riusciti a fare questo, anche se, apparentemente, il problema del prezzo non dovrebbe esistere — si tratta infatti della nostra soluzione. Inoltre, sorge la questione di come collegare il sensore in questo caso? In interruzione? E se il sensore stesso si guasta? Richiedere un modulo di bypass nel sensore? Utilizzare i tap? Tutto ciò aumenta il costo della soluzione e la rende insostenibile per aziende di qualsiasi dimensione.
È possibile provare a "installare" un sensore su una porta SPAN/RSPAN/ERSPAN e indirizzare su di essa il traffico dalle porte necessarie dello switch. Questa opzione allevia parzialmente il problema descritto nel paragrafo precedente, ma ne solleva un altro: la porta SPAN non può ricevere tutto il traffico che verrà indirizzato verso di essa, poiché non ha sufficiente capacità di banda. Sarà necessario sacrificare qualcosa. O mantenere alcune nodi sotto monitoraggio (in tal caso sarà necessario prima effettuare una loro priorizzazione), oppure inviare non tutto il traffico da un nodo, ma solo un determinato tipo. In ogni caso, potremmo perdere alcuni attacchi. Inoltre, la porta SPAN potrebbe essere occupata per altre esigenze. Alla fine, dovremo rivedere la topologia di rete esistente e apportare, forse, delle correzioni per coprire al massimo la vostra rete con il numero di sensori a vostra disposizione (e concordare ciò con IT).
E se la vostra rete utilizza percorsi asimmetrici? E se avete implementato o state pianificando di implementare SDN? E se dovete monitorare macchine virtuali o container, il cui traffico non raggiunge affatto lo switch fisico? Queste domande non piacciono ai produttori di IDS tradizionali, perché non sanno come rispondere. Potrebbero tentarvi a pensare che tutte queste tecnologie di moda siano solo un hype e che non ne abbiate bisogno. Potrebbero parlare dell'esigenza di iniziare in piccolo. O forse diranno che dovete installare un potente dispositivo al centro della rete e indirizzare tutto il traffico verso di esso tramite bilanciatori. Qualunque opzione vi venga proposta, è necessario capire chiaramente quanto sia adatta a voi. E solo dopo prendere una decisione sul tipo di approccio da utilizzare per il monitoraggio della sicurezza della rete. Tornando alla cattura dei pacchetti, voglio sottolineare che questo metodo rimane molto popolare e importante, ma il suo scopo principale è il controllo dei confini; i confini tra la vostra organizzazione e Internet, i confini tra il data center e il restante della rete, i confini tra l'automazione dei sistemi e il segmento aziendale. In questi punti, gli IDS/IPS classici hanno ancora diritto a esistere e svolgono bene i compiti assegnati.
Passiamo alla seconda opzione. L'analisi degli eventi provenienti dai dispositivi di rete può essere utilizzata anche per scopi di rilevamento delle intrusioni, ma non come meccanismo principale, poiché consente di rilevare solo una piccola classe di intrusioni. Inoltre, presenta una certa reattività: un attacco deve prima verificarsi, poi deve essere registrato dal dispositivo di rete, il quale, in un modo o nell'altro, segnalerà il problema con la sicurezza informatica. Ci sono diversi modi per farlo. Può essere syslog, RMON o SNMP. Gli ultimi due protocolli per il monitoraggio di rete nel contesto della sicurezza informatica vengono utilizzati solo se è necessario rilevare un attacco DoS sull'hardware di rete stesso, poiché con RMON e SNMP è possibile, ad esempio, monitorare il carico della CPU del dispositivo o delle sue interfacce. Questo è uno dei metodi più 'economici' (syslog o SNMP sono disponibili per tutti), ma anche il meno efficace per il monitoraggio della sicurezza informatica dell'infrastruttura interna: molte intrusioni gli sfuggono. È ovvio che non devono essere trascurati, e lo stesso analisi di syslog aiuta a identificare tempestivamente le modifiche nella configurazione del dispositivo, la compromissione di esso, ma non è molto adatto per rilevare attacchi all'intera rete.
La terza opzione è l'analisi delle informazioni sul traffico che passa attraverso un dispositivo che supporta uno dei vari protocolli di flusso. In questo caso, indipendentemente dal protocollo, l'infrastruttura di lavoro con i flussi consiste necessariamente di tre componenti:
- Generazione o esportazione del flusso. Questo compito è solitamente affidato a un router, uno switch o un altro dispositivo di rete che, passando attraverso di esso, permette di estrarre dal traffico di rete parametri chiave che poi vengono inviati al modulo di raccolta. Ad esempio, nel caso di Cisco, il protocollo Netflow è supportato non solo su router e switch, inclusi quelli virtuali e industriali, ma anche su controller wireless, firewall e persino server.
- Raccolta del flusso. Tenendo presente che in una rete moderna ci sono di solito più di un dispositivo di rete, sorge la necessità di raccogliere e consolidare i flussi, che viene risolta tramite i cosiddetti collezionisti, che elaborano i flussi ricevuti e poi li trasmettono per l'analisi.
- Analisi del flow. L'analizzatore assume il compito intellettuale principale e, applicando algoritmi diversi ai flussi, trae varie conclusioni. Ad esempio, nell'ambito della funzione IT, tale analizzatore può identificare colli di bottiglia nella rete o analizzare il profilo di carico del traffico per ulteriori ottimizzazioni della rete. Per la sicurezza informatica, tale analizzatore può rilevare perdite di dati, diffusione di malware o attacchi DoS.
Non bisogna pensare che un'architettura a tre livelli sia troppo complessa: tutte le altre varianti (escludendo, forse, i sistemi di monitoraggio della rete che operano con SNMP e RMON) funzionano ugualmente secondo questa logica. Abbiamo un generatore di dati per l'analisi, il quale può essere un dispositivo di rete o un sensore autonomo. Abbiamo un sistema di raccolta degli allarmi e un sistema di gestione dell'intera infrastruttura di monitoraggio. Questi ultimi due componenti possono essere combinati all'interno di un unico nodo, ma in reti di dimensioni più o meno grandi sono generalmente distribuiti su almeno due dispositivi per garantire scalabilità e affidabilità.
A differenza dell'analisi dei pacchetti, che si basa sullo studio dell'intestazione e del corpo di ogni pacchetto, e delle sessioni che ne derivano, l'analisi dei flussi si basa sulla raccolta di metadati sul traffico di rete. Quando, quanto, da dove e dove, come... queste sono le domande a cui risponde l'analisi della telemetria di rete tramite vari protocolli di flow. Inizialmente, erano utilizzati per analizzare statistiche e rilevare problemi IT nella rete, ma successivamente, con l'evoluzione dei meccanismi analitici, è stato possibile applicarli alla stessa telemetria anche per scopi di sicurezza. È importante sottolineare che l'analisi dei flussi non sostituisce né annulla la cattura dei pacchetti. Ognuno di questi metodi ha la sua area di applicazione. Tuttavia, nel contesto di questo articolo, l'analisi dei flussi è la più adatta per il monitoraggio dell'infrastruttura interna. Hai dispositivi di rete (e non importa se funzionano nella logica della programmazione definita dal software o secondo regole statiche) che non possono essere aggirati dall'attacco. Un sensore classico IDS può essere bypassato, mentre un dispositivo di rete che supporta il protocollo flow no. Questo è il vantaggio di questo metodo.
D'altra parte, se hai bisogno di una base di prove per le forze dell'ordine o per il tuo gruppo di investigazione sugli incidenti, non puoi fare a meno della cattura dei pacchetti: la telemetria di rete non è una copia del traffico che può essere utilizzata per raccogliere prove; è necessaria per la rilevazione operativa e la presa di decisioni in ambito di sicurezza informatica. D'altra parte, utilizzando l'analisi della telemetria, puoi "scrivere" non tutto il traffico di rete (per chi non lo sapesse, Cisco si occupa di data center :-), ma solo quello che partecipa all'attacco. Gli strumenti di analisi della telemetria in questo senso completano bene i tradizionali meccanismi di cattura dei pacchetti, fornendo un comando per la cattura e la conservazione selettiva. Altrimenti, dovrai avere un'infrastruttura di archiviazione colossale.
Immagina una rete che funziona a una velocità di 250 Mbit/s. Se desideri conservare tutto questo volume, avrai bisogno di uno spazio di archiviazione di 31 MB per un secondo di trasmissione dei dati, 1,8 GB per un minuto, 108 GB per un'ora e 2,6 TB per un giorno. Per archiviare i dati giornalieri di una rete con una larghezza di banda di 10 Gbit/s, avrai bisogno di uno spazio di archiviazione di 108 TB. E alcune normative richiedono di conservare i dati sulla sicurezza per anni... La registrazione "su richiesta" che l'analisi del flusso ti aiuta a realizzare permette di ridurre questi valori di ordini di grandezza. A proposito, parlando del rapporto tra il volume di dati registrati dalla telemetria di rete e la cattura completa dei dati, è di circa 1 a 500. Per i valori menzionati sopra, la memorizzazione della decodifica completa dell'intero traffico giornaliero sarà di 5 e 216 GB rispettivamente (puoi anche registrarlo su una normale chiavetta USB).
Se per gli strumenti di analisi dei dati di rete grezzi il metodo di acquisizione non differisce molto da fornitore a fornitore, nel caso dell'analisi dei flussi la situazione è diversa. Esistono diversi protocolli flow, delle differenze dei quali è necessario essere a conoscenza, soprattutto nel contesto della sicurezza. Il protocollo più popolare è Netflow, sviluppato da Cisco. Ci sono diverse versioni di questo protocollo, che differiscono per capacità e volume di informazioni sul traffico registrato. La versione attuale è la nona (Netflow v9), su cui è stato sviluppato lo standard industriale Netflow v10, noto anche come IPFIX. Oggi la maggior parte dei fornitori di rete supporta proprio Netflow o IPFIX nel proprio hardware. Ma ci sono anche altri tipi di protocolli flow: sFlow, jFlow, cFlow, rFlow, NetStream e così via, tra i quali sFlow è il più popolare. Questo è spesso supportato dai produttori nazionali di apparecchiature di rete a causa della sua semplicità di implementazione. Quali sono le principali differenze tra Netflow, che è diventato uno standard de facto, e lo stesso sFlow? Ne evidenzierei alcune. In primo luogo, Netflow ha campi personalizzabili dall'utente, a differenza dei campi fissi in sFlow. In secondo luogo, e questo è il punto più importante nel nostro caso, sFlow raccoglie quella che viene definita telemetria campionata; a differenza della telemetria non campionata di Netflow e IPFIX. Qual è, quindi, la differenza tra di loro?
Immaginate di aver deciso di conoscere il libro “” dei miei colleghi — Gary McIntyre, Joseph Muniz e Nadeem AlFardan (al link potete scaricare una parte del libro). Avete tre opzioni per raggiungere l'obiettivo: leggere il libro per intero, scorgerne il contenuto fermandovi ogni 10° o 20° pagina, oppure cercare un riassunto dei concetti chiave in qualche blog o servizio tipo SmartReading. La telemetria non campionata equivale a leggere ogni “pagina” del traffico di rete, cioè analizzare i metadati di ogni pacchetto. La telemetria campionata è uno studio selettivo del traffico nella speranza di trovare quello che serve all'interno dei campioni scelti. A seconda della velocità della connessione, la telemetria campionata analizzerà ogni 64°, 200°, 500°, 1000°, 2000° o anche 10000° pacchetto.
Nel contesto del monitoraggio della sicurezza informatica, questo significa che la telemetria campionata è ben adatta per rilevare attacchi DDoS, scansioni, diffusione di malware, ma può trascurare attacchi atomici o multi-packet che non rientrano nel campione inviato per l'analisi. La telemetria non campionata non ha questi svantaggi e, grazie a essa, lo spettro degli attacchi rilevabili è notevolmente più ampio. Ecco un breve elenco di eventi che possono essere rilevati con strumenti di analisi della telemetria di rete.
Naturalmente, un'analizzatore Netflow open source non vi permetterà di farlo, poiché il suo compito principale è raccogliere la telemetria e condurre un'analisi di base dal punto di vista IT. Per rilevare minacce informatiche basate su flow, è necessario equipaggiare l'analizzatore con vari motori e algoritmi, che identificheranno i problemi di cybersecurity sulla base di campi Netflow standard o personalizzati, arricchendo i dati standard con informazioni esterne provenienti da diverse fonti di Threat Intelligence, e così via.
Quindi, se avete la possibilità, scegliete Netflow o IPFIX. Ma anche se il vostro hardware supporta solo sFlow, come nel caso dei produttori nazionali, potete comunque trarne vantaggio in termini di sicurezza.
Nell'estate del 2019, ho effettuato un'analisi delle capacità disponibili presso i produttori russi di hardware di rete, e tutti loro, ad eccezione di NSG, Poligono e Kraftway, hanno dichiarato di supportare sFlow (almeno, Zelax, Natex, Eltex, QTech, Rusteletech).
La domanda successiva che vi porrete è: dove implementare il supporto flow per obiettivi di sicurezza? In realtà, la domanda è posta in modo non del tutto corretto. Sull’hardware moderno, il supporto ai protocolli flow è quasi sempre presente. Pertanto, riformulerei la domanda in questo modo: dove è più efficace raccogliere la telemetria dal punto di vista della sicurezza? La risposta sarà piuttosto ovvia: a livello di accesso, dove vedrete il 100% di tutto il traffico, dove avrete informazioni dettagliate sugli host (MAC, VLAN, ID interfaccia), dove potrete monitorare anche il traffico P2P tra gli host, il che è cruciale per rilevare scansioni e la diffusione di malware. A livello del kernel, parte del traffico potrebbe non essere visibile, mentre a livello di perimetro vedrete a malapena un quarto di tutto il vostro traffico di rete. Ma se per qualche motivo nella vostra rete ci sono dispositivi estranei che consentono agli aggressori di 'entrare e uscire', bypassando il perimetro, l'analisi della telemetria non vi servirà a nulla. Pertanto, per una copertura massima, si raccomanda di abilitare la raccolta della telemetria proprio a livello di accesso. Vale la pena notare che, anche parlando di virtualizzazione o contenitori, nei moderni switch virtuali il supporto flow è spesso presente, permettendo di controllare il traffico anche lì.
Ma dato che ho sollevato l'argomento, occorre rispondere alla domanda: e se l'hardware, fisico o virtuale, non supporta i protocolli flow? Oppure se la loro attivazione è vietata (ad esempio nei segmenti industriali per garantire l'affidabilità)? O se la loro attivazione comporta un alto carico della CPU (cosa che può succedere su hardware obsoleto)? Per affrontare questa problematica esistono sensori virtuali specializzati (flow sensor), che in sostanza sono comuni hub che fanno passare il traffico attraverso di essi e lo trasmettono come flow a un modulo di raccolta. Tuttavia, in questo caso ci troviamo ad affrontare un'intera serie di problemi, come abbiamo discusso sopra riguardo ai mezzi di intercettazione dei pacchetti. Quindi, è necessario comprendere non solo i vantaggi della tecnologia di analisi dei flussi, ma anche i suoi limiti.
Un altro aspetto importante da tenere a mente quando si parla degli strumenti di analisi del flusso. Se per quanto riguarda i normali strumenti di generazione di eventi di sicurezza utilizziamo la metrica EPS (eventi al secondo), per l'analisi della telemetria questo indicatore non è applicabile; viene sostituito da FPS (flussi al secondo). Così come nel caso dell'EPS, non è possibile calcolarlo in anticipo, ma si può stimare il numero approssimativo di flussi generati da un dispositivo in base al suo compito. Puoi trovare tabelle su Internet con valori approssimativi per diversi tipi di dispositivi aziendali e condizioni, che ti permetteranno di ipotizzare quali licenze ti servono per gli strumenti di analisi e quale sarà la loro architettura. Il fatto è che il sensore IDS ha una capacità di filtraggio limitata che può "sostenere" e anche il collettore di flussi ha le sue limitazioni che è necessario comprendere. Pertanto, nelle reti ampie e territorialmente distribuite ci sono di solito più collettori. Quando parlavo di , ho già citato il nostro numero di collettori: sono 21. E questo per una rete distribuita su cinque continenti e composta da circa mezzo milione di dispositivi attivi).
Come sistema di monitoraggio Netflow utilizziamo la nostra soluzione , progettato specificamente per affrontare le sfide della sicurezza. Ha molti motori integrati per la rilevazione di attività anomale, sospette e manifestamente dannose, consentendo di rilevare un'ampia gamma di minacce, dal mining di criptovalute alle fughe di informazioni, dalla diffusione di malware alle frodi. Come la maggior parte degli analizzatori di flusso, Stealthwatch è costruito su uno schema a tre livelli (generatore - raccoglitore - analizzatore), ma è arricchito da una serie di interessanti caratteristiche che sono importanti nel contesto del materiale trattato. Innanzitutto, si integra con soluzioni di cattura dei pacchetti (ad esempio, Cisco Security Packet Analyzer), consentendo di registrare sessioni di rete selezionate per successivi approfondimenti e analisi. In secondo luogo, per ampliare le capacità di sicurezza, abbiamo sviluppato un protocollo speciale chiamato nvzFlow, che consente di
È chiaro che parlando dei sistemi di analisi Netflow in termini di sicurezza, il mercato non è limitato a una sola soluzione di Cisco. È possibile utilizzare sia soluzioni commerciali che gratuite o parzialmente gratuite. È piuttosto strano se nel blog di Cisco cito come esempio soluzioni dei concorrenti, quindi dirò qualche parola su come la telemetria di rete può essere analizzata utilizzando due strumenti popolari, simili nel nome, ma comunque diversi: SiLK e ELK.
SiLK è un insieme di strumenti (the System for Internet-Level Knowledge) per l'analisi del traffico, sviluppato dall'CERT/CC americano e che supporta, nel contesto dell'articolo odierno, Netflow (le versioni 5 e 9, le più popolari), IPFIX e sFlow e attraverso varie utilità (rwfilter, rwcount, rwflowpack, ecc.) eseguire varie operazioni sulla telemetria di rete per rilevare segni di attività non autorizzate. Ma è necessario sottolineare un paio di punti importanti. SiLK è uno strumento da linea di comando e condurre analisi operative, richiede continuamente l'immissione di comandi del tipo (rilevamento di pacchetti ICMP di dimensione superiore a 200 byte):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
non è molto comodo. Puoi utilizzare l'interfaccia grafica iSiLK, ma non ti faciliterà molto la vita, risolvendo solo la funzione di visualizzazione, non sostituendo l'analista. E questo è il secondo punto. A differenza delle soluzioni commerciali, che già includono una solida base analitica, algoritmi per il rilevamento delle anomalie, flussi di lavoro e così via, nel caso di SiLK dovrai fare tutto questo da solo, il che richiederà da te competenze leggermente diverse rispetto all'uso di strumenti già pronti all'uso. Questo non è né buono né cattivo — è una caratteristica di quasi tutti gli strumenti gratuiti, che presuppongono che tu sappia cosa fare e che l'utensile ti aiuterà in questo (gli strumenti commerciali dipendono meno dalle competenze degli utenti, sebbene presuppongano comunque che gli analisti comprendano almeno le basi delle indagini e del monitoraggio della rete). Ma torniamo a SiLK. Il ciclo di lavoro di un analista con esso appare come segue:
- Formulazione dell'ipotesi. Dobbiamo capire cosa cercheremo all'interno della telemetria di rete, conoscere gli attributi unici con cui identificheremo le varie anomalie o minacce.
- Costruzione del modello. Dopo aver formulato l'ipotesi, programmiamo la stessa utilizzando Python, shell o altri strumenti non inclusi in SiLK.
- Testing. Arriva il momento di verificare la correttezza della nostra ipotesi, che viene confermata o smentita attraverso le utilità di SiLK, che iniziano con 'rw', 'set', 'bag'.
- Analisi dei dati reali. Nella gestione industriale, SiLK ci aiuta a identificare qualcosa e l'analista deve rispondere alle domande "Abbiamo trovato ciò che ci aspettavamo?", "Questo corrisponde alla nostra ipotesi?", "Come ridurre il numero di falsi allarmi?", "Come migliorare il tasso di riconoscimento?" e così via.
- Miglioramento. Nella fase finale, miglioriamo quanto fatto in precedenza: creiamo modelli, ottimizziamo e raffiniamo il codice, riformuliamo e chiarifichiamo l'ipotesi, e altro ancora.
Questo ciclo sarà applicabile anche a Cisco Stealthwatch, solo che quest'ultimo automatizza questi cinque passaggi al massimo, riducendo il numero di errori dell'analista e aumentando la tempestività nella rilevazione degli incidenti. Ad esempio, in SiLK puoi arricchire le statistiche di rete con dati esterni su indirizzi IP malevoli utilizzando script scritti a mano, mentre in Cisco Stealthwatch questa è una funzione integrata che ti mostra immediatamente un segnale di allerta se nel traffico di rete si verifica un'interazione con indirizzi IP in una blacklist.
Se si sale nella piramide "di costo" per il software di analisi del flusso, a SiLK, completamente gratuito, segue un ELK condizionatamente gratuito, composto da tre componenti chiave: Elasticsearch (indicizzazione, ricerca e analisi dei dati), Logstash (input/output dei dati) e Kibana (visualizzazione). A differenza di SiLK, dove bisogna scrivere tutto da soli, ELK ha già molte librerie/moduli pronti (alcuni a pagamento, altri no) che automatizzano l'analisi della telemetria di rete. Ad esempio, il filtro GeoIP in Logstash consente di associare gli indirizzi IP osservati alla loro posizione geografica (mentre Stealthwatch ha questa funzione integrata).
ELK ha anche una community abbastanza ampia che scrive componenti mancanti per questa soluzione di monitoraggio. Ad esempio, per lavorare con Netflow, IPFIX e sFlow, puoi utilizzare il modulo , se non sei soddisfatto del modulo Logstash Netflow, che supporta solo Netflow.
Anche se offre maggiore tempestività nella raccolta di flussi e nella loro ricerca, ELK al momento non ha un'analisi integrata ricca per la rilevazione di anomalie e minacce nella telemetria di rete. Ciò significa che seguendo il ciclo di vita descritto in precedenza, dovrai descrivere autonomamente i modelli di violazione e poi utilizzarli nel sistema operativo (non ci sono modelli integrati).
Ci sono naturalmente estensioni più sofisticate per ELK, che già includono alcuni modelli per l'individuazione di anomalie nella telemetria di rete, ma queste estensioni costano e qui sorge la domanda se valga la pena — scrivere un modello simile da soli, acquistare la sua implementazione per il proprio strumento di monitoraggio o comprare una soluzione pronta nella classe Network Traffic Analysis.
In realtà, non voglio entrare in polemica su cosa sia meglio, spendere soldi e acquistare una soluzione pronta per il monitoraggio di anomalie e minacce nella telemetria di rete (ad esempio, Cisco Stealthwatch) oppure risolvere autonomamente e adattare SiLK, ELK o nfdump o OSU Flow Tools a ogni nuova minaccia (parlo degli ultimi due di essi, dalla volta scorsa)? Ognuno sceglie per sé e ognuno ha le proprie motivazioni per scegliere una delle due opzioni. Volevo solo mostrare che la telemetria di rete è uno strumento molto importante per garantire la sicurezza della rete della propria infrastruttura interna e non dovrebbe essere trascurato, per non unirsi alla lista di aziende il cui nome viene menzionato nei media con epiteti come “hackerate”, “che non rispettavano i requisiti di sicurezza informatica”, “che non pensano alla sicurezza dei propri dati e a quelli dei clienti”. In conclusione, vorrei elencare alcuni consigli chiave ai quali vale la pena attenersi nella strutturazione del monitoraggio della sicurezza informatica della propria infrastruttura interna:
Non limitatevi solo al perimetro! Utilizzate (e scegliete) l'infrastruttura di rete non solo per il trasferimento del traffico da un punto A a un punto B, ma anche per affrontare questioni di sicurezza informatica.
- Esplorate i meccanismi di monitoraggio della sicurezza informatica esistenti nel vostro hardware di rete e sfruttateli.
- Per il monitoraggio interno, date la preferenza all'analisi della telemetria: consente di rilevare fino all'80-90% di tutti gli incidenti di sicurezza informatica, facendo ciò che non è possibile con la cattura dei pacchetti di rete e risparmiando spazio di archiviazione per tutti gli eventi di sicurezza informatica.
- Per il monitoraggio dei flussi utilizzate Netflow v9 o IPFIX: forniscono più informazioni nel contesto della sicurezza e permettono di monitorare non solo IPv4, ma anche IPv6, MPLS, ecc.
- Utilizzate un protocollo di flusso non campionato: fornisce maggiori informazioni per la rilevazione delle minacce. Ad esempio, Netflow o IPFIX.
- Sfruttate un protocollo di flusso non campionato: offre più dettagli per la rilevazione delle minacce. Ad esempio, Netflow o IPFIX.
- Controlla il caricamento delle tue apparecchiature di rete: potrebbe non riuscire a gestire anche il protocollo flow. In tal caso, considera l'applicazione di sensori virtuali o di un Netflow Generation Appliance.
- Implementa il controllo principalmente a livello di accesso: questo ti darà la possibilità di vedere il 100% di tutto il traffico.
- Se non hai scelta e stai utilizzando apparecchiature di rete russe, scegli quelle che supportano i protocolli flow o dispongono di porte SPAN/RSPAN.
- Combina sistemi di rilevazione/prevenzione delle intrusioni ai confini con sistemi di analisi del traffico all'interno della rete (compresi i cloud).
Per quanto riguarda l'ultimo consiglio, vorrei portare un'illustrazione che ho già menzionato in precedenza. Vedi che se in passato il servizio di sicurezza Cisco costruiva quasi interamente il proprio sistema di monitoraggio della sicurezza basandosi su sistemi di rilevazione delle intrusioni e metodi basati su firme, ora solo il 20% degli incidenti ricade su di essi. Un altro 20% è basato sui sistemi di analisi del traffico, il che indica che queste soluzioni non sono un capriccio, ma strumenti reali nell'attività dei servizi di sicurezza delle moderne imprese. Inoltre, hai per la loro implementazione ciò che è più importante: l'infrastruttura di rete, il cui investimento può essere ulteriormente protetto assegnando funzioni di monitoraggio della sicurezza alla rete.
Ho scelto di non trattare il tema della reazione alle anomalie o minacce rilevate nei flussi di rete, ma penso sia chiaro che il monitoraggio non deve fermarsi solo alla rilevazione della minaccia. Dovrebbe essere seguito da una reazione, preferibilmente in modalità automatica o automatizzata. Ma questo è già un argomento per un altro materiale.
Informazioni aggiuntive:
PS. Se ti è più facile percepire a voce tutto ciò che è stato scritto sopra, puoi guardare una presentazione di un'ora che ha servito da base per questa nota.
Fonte: habr.com
