Quando si parla di monitoraggio della sicurezza di una rete aziendale o governativa, molti associano immediatamente il termine al controllo delle perdite di informazioni e all'implementazione di soluzioni DLP. Ma se proviamo a precisare la domanda e a chiedere come si rilevano gli attacchi all'interno della rete, la risposta sarà generalmente un riferimento ai sistemi di rilevamento delle intrusioni (intrusion detection systems, IDS). Ciò che una volta rappresentava l'unica opzione, circa 10-20 anni fa, oggi risulta obsoleto. Esiste una soluzione più efficace, se non l'unica possibile, per il monitoraggio della rete interna: utilizzare i protocolli flow, inizialmente concepiti per la risoluzione di problemi di rete (troubleshooting), ma nel tempo trasformatisi in uno strumento di sicurezza molto interessante. In questo articolo parleremo dei diversi tipi di protocolli flow, di quali siano i migliori per rilevare attacchi di rete, di dove sia più efficace implementare il monitoraggio flow, di cosa tenere in considerazione durante la configurazione di questo schema e persino di come realizzarlo su attrezzature nazionali.
Non mi soffermerò sulla domanda “Perché è necessario monitorare la sicurezza dell'infrastruttura interna?” La risposta sembra abbastanza chiara. Tuttavia, se volevate ulteriori conferme, oggi non si può fare a meno di questo. un breve video che illustra 17 modi per infiltrarsi in una rete aziendale protetta da un firewall. Pertanto, consideriamo di comprendere che il monitoraggio interno è imprescindibile e resta solo da capire come può essere organizzato.
Identificherei tre fonti chiave di dati per il monitoraggio dell'infrastruttura a livello di rete:
- il traffico “grezzo”, che catturiamo e analizziamo con apposite sistemi di analisi,
- gli eventi provenienti dai dispositivi di rete attraverso cui passa il traffico,
- le informazioni sul traffico ottenute tramite uno dei protocolli flow.
La cattura del traffico grezzo è l'opzione più popolare per i professionisti della sicurezza, poiché è storicamente la prima a essere emersa. I tradizionali sistemi di rilevamento delle intrusioni (la prima soluzione commerciale è stata NetRanger della Wheel Group, acquisita da Cisco nel 1998) si occupavano appunto della cattura dei pacchetti (e successivamente delle sessioni), in cui venivano cercate determinate firme (“regole decisive” nella terminologia del FSTEC), che segnalano attacchi. Naturalmente, è possibile analizzare il traffico grezzo non solo attraverso l'IDS, ma anche utilizzando altri strumenti (ad esempio, Wireshark, tcpdump o la funzionalità NBAR2 in Cisco IOS), ma di solito questi ultimi non dispongono di un database di conoscenze che distingue lo strumento di sicurezza informatica da un comune strumento IT.
Quindi, i sistemi di rilevamento delle intrusioni. Il metodo più antico e popolare per rilevare attacchi di rete, che svolge bene il proprio compito al confine (che sia aziendale, in un centro dati, segmento, ecc.), ma che inciampa nelle moderne reti commutate e definite dal software. Nel caso di una rete costruita su comuni switch, l'infrastruttura dei sensori per la rilevazione delle intrusioni diventa troppo grande: è necessario installare un sensore per ogni connessione con il nodo che si desidera monitorare. Qualsiasi produttore sarà ovviamente felice di vendervi centinaia e migliaia di sensori, ma penso che il vostro budget non reggerebbe tali spese. Posso dirvi che anche in Cisco (essendo noi sviluppatori di NGIPS) non siamo riusciti a farlo, sebbene, a prima vista, il problema del costo non dovrebbe presentarci una difficoltà — è pur sempre la nostra soluzione. Inoltre, rimane la questione di come collegare il sensore in questa situazione? In interruzione? E se il sensore stesso dovesse guastarsi? È necessario richiedere un modulo bypass nel sensore? Utilizzare splitter (tap)? Tutto ciò aumenta i costi e rende la soluzione inaccessibile per qualsiasi azienda.
È possibile provare a "collegare" un sensore a una porta SPAN/RSPAN/ERSPAN e dirigere su di essa il traffico dalle porte necessarie dello switch. Questa soluzione allevia parzialmente il problema descritto nel paragrafo precedente, ma ne pone un altro: la porta SPAN non può gestire tutto il traffico che verrà diretto su di essa, poiché non avrà sufficiente larghezza di banda. Sarà necessario sacrificare qualcosa. O lasciare alcuni nodi non monitorati (in tal caso è necessario prioritizzarli in anticipo), oppure indirizzare solo un tipo specifico di traffico da un nodo. In ogni caso, potremmo perdere alcune attacchi. Inoltre, la porta SPAN potrebbe essere occupata per altri scopi. Alla fine, dovremo riesaminare l'attuale topologia di rete e apportare, forse, delle modifiche per massimizzare la copertura della rete con il numero attuale di sensori disponibili (e allineare questo con l'IT).
E se la tua rete utilizza percorsi asimmetrici? E se hai implementato o prevedi di implementare SDN? E se hai bisogno di monitorare macchine virtualizzate o contenitori il cui traffico non raggiunge affatto lo switch fisico? Queste domande non piacciono ai produttori di IDS tradizionali, poiché non sanno come rispondere. Potrebbero cercare di convincerti che tutte queste tecnologie di tendenza sono solo un hype di cui non hai bisogno. Potrebbero suggerire di cominciare in piccolo. O magari diranno che devi installare una potente macchina centrale della rete e deviare tutto il traffico verso di essa usando i bilanciatori. Qualunque sia la proposta, è fondamentale comprendere chiaramente quanto ti si addice. Solo dopo averlo fatto potrai prendere una decisione sul metodo di monitoraggio della sicurezza della rete. Tornando alla cattura dei pacchetti, desidero sottolineare che questo metodo rimane molto popolare e importante, ma il suo scopo principale è il controllo dei confini; confini tra la tua organizzazione e Internet, confini tra il data center e il resto della rete, confini tra il sistema di controllo e il segmento corporate. In questi punti, gli IDS/IPS classici hanno ancora ragione di esistere e si destreggiano bene nei compiti assegnati.
Passiamo alla seconda opzione. L'analisi degli eventi provenienti dai dispositivi di rete può essere utilizzata per la rilevazione degli attacchi, ma non come meccanismo principale, poiché consente di rilevare solo una ristretta classe di intrusi. Inoltre presenta una certa reattività: l'attacco deve prima verificarsi, quindi deve essere registrato dal dispositivo di rete, che in un modo o nell'altro segnalerà un problema di 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 scoprire un attacco DoS all'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 modi più "economici" (syslog o SNMP sono disponibili per tutti), ma anche il meno efficace tra tutti i metodi di monitoraggio della sicurezza informatica dell'infrastruttura interna: molti attacchi sono semplicemente nascosti a questo sistema. Naturalmente, non bisogna trascurarli e lo stesso analisi del syslog aiuta a identificare tempestivamente le modifiche nella configurazione del dispositivo, la sua compromissione, ma non è molto adatto per rilevare attacchi su tutta la rete.
La terza opzione consiste nell'analisi delle informazioni sul traffico che passa attraverso un dispositivo che supporta uno dei vari protocolli flow. In questo caso, indipendentemente dal protocollo, l'infrastruttura di gestione dei flussi deve necessariamente consistere di tre componenti:
- Generazione o esportazione del flow. Questo compito è solitamente affidato a un router, uno switch o un altro dispositivo di rete che, passando attraverso il traffico di rete, consente di estrarre i parametri chiave che vengono poi inviati al modulo di raccolta. Ad esempio, in Cisco, il protocollo Netflow è supportato non solo su router e switch, comprese le versioni virtuali e industriali, ma anche su controller wireless, firewall e persino server.
- Raccolta del flow. Considerato che in una rete moderna ci sono di solito più di un dispositivo di rete, si pone la questione della raccolta e della consolidazione dei flussi, soluzione che viene realizzata tramite cosiddetti collezionisti, che elaborano i flussi ricevuti e poi li inviano per l'analisi.
- Analisi del flow. L'analizzatore si assume il compito intellettuale principale e, applicando vari algoritmi ai flussi, trae determinate conclusioni. Ad esempio, nell'ambito delle funzioni IT, un tale analizzatore può identificare colli di bottiglia nella rete o analizzare il profilo di carico del traffico per un'ulteriore ottimizzazione della rete. Per la sicurezza informatica, un analizzatore simile può rilevare perdite di dati, diffusione di codice dannoso o attacchi DoS.
Non bisogna pensare che un'architettura a tre livelli sia troppo complessa: tutte le altre opzioni (eccetto, forse, i sistemi di monitoraggio della rete che funzionano con SNMP e RMON) seguono la stessa logica. Abbiamo un generatore di dati per l'analisi, che può essere un dispositivo di rete o un sensore standalone. Abbiamo un sistema di raccolta degli allarmi e un sistema di gestione dell'intera infrastruttura di monitoraggio. Gli ultimi due componenti possono essere combinati in un'unica unità, ma in reti di dimensioni più o meno grandi sono solitamente distribuiti su almeno due dispositivi per garantire scalabilità e affidabilità.
A differenza dell'analisi dei pacchetti, che si basa sull'esame dell'intestazione e del corpo di ciascun pacchetto e delle sessioni ad essi collegate, l'analisi dei flussi si fonda sulla raccolta di metadati sul traffico di rete. Quando, quanto, da dove e dove, come... ecco le domande a cui risponde l'analisi della telemetria di rete tramite vari protocolli flow. Inizialmente, questi venivano utilizzati per analizzare le statistiche e risolvere 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 e non annulla la cattura dei pacchetti. Ognuno di questi metodi ha il proprio ambito di applicazione. Tuttavia, nel contesto di questo articolo, l'analisi dei flussi è particolarmente adatta per il monitoraggio dell'infrastruttura interna. Hai dispositivi di rete (e non importa se operano in una modalità programmabile o secondo regole statiche) che non possono essere aggirati da un attacco. Un sensore IDS classico può essere bypassato, ma un dispositivo di rete che supporta il protocollo flow no. Questo è il vantaggio di questo metodo.
D'altra parte, se hai bisogno di prove per le forze dell'ordine o per un tuo gruppo di indagine 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 indizi; è necessaria per la rilevazione rapida e la presa di decisioni nel campo della sicurezza informatica. Al contrario, utilizzando l'analisi della telemetria, puoi "catturare" solo il traffico di rete che partecipa all'attacco. Gli strumenti di analisi della telemetria, in questo senso, completano bene i tradizionali meccanismi di cattura dei pacchetti, dando il via a una cattura e conservazione selettiva. In caso contrario, dovrai avere un'infrastruttura di storage colossale.
Immaginate una rete che funziona a una velocità di 250 Mbit/s. Se desiderate archiviare tutto questo volume, avrete bisogno di uno spazio di 31 MB per ogni secondo di traffico, 1,8 GB per un minuto, 108 GB per un'ora e 2,6 TB per un giorno. Per memorizzare i dati giornalieri da una rete con una larghezza di banda di 10 Gbit/s, avrete bisogno di 108 TB di spazio. E alcuni regolatori richiedono di conservare i dati per motivi di sicurezza per anni... La registrazione «su richiesta», che l'analisi del flusso aiuta a realizzare, può ridurre questi valori di molti ordini di grandezza. A proposito, se parliamo del rapporto tra il volume dei dati registrati dalla telemetria di rete e l'acquisizione completa dei dati, è di circa 1 a 500. Per i valori sopra menzionati, la memorizzazione della decodifica completa di tutto il traffico giornaliero richiederebbe rispettivamente 5 e 216 GB (può persino essere registrato su una normale chiavetta USB).
Se per gli strumenti di analisi dei dati di rete grezzi il metodo di cattura non differisce molto da un fornitore all'altro, nel caso dell'analisi dei flussi la situazione è diversa. Esistono diversi protocolli di flusso, di cui è importante conoscere le differenze, soprattutto in contesto di sicurezza. Il protocollo più popolare è il Netflow, sviluppato da Cisco. Ci sono diverse versioni di questo protocollo, che variano per capacità e volume di informazioni sul traffico registrato. La versione attuale è la nona (Netflow v9), sulla quale è stato sviluppato lo standard industriale Netflow v10, noto anche come IPFIX. Oggi la maggior parte dei fornitori di networking supporta Netflow o IPFIX nei propri dispositivi. Tuttavia, esistono anche diverse altre varianti di protocolli di flusso — sFlow, jFlow, cFlow, rFlow, NetStream, e così via, tra cui sFlow è il più popolare. Questo protocollo è spesso supportato dai produttori nazionali di apparecchiature di rete a causa della sua semplicità di implementazione. Quali sono le principali differenze tra Netflow, diventato di fatto uno standard, e sFlow? Ne evidenzierei alcune. In primo luogo, Netflow ha campi personalizzabili dall'utente, a differenza dei campi fissi di sFlow. In secondo luogo, ed è il punto principale nel nostro caso, sFlow raccoglie una telemetria campionata, a differenza della telemetria non campionata di Netflow e IPFIX. Qual è dunque la differenza tra di loro?
Immagina di voler esaminare il libro “” dei miei colleghi — Gary McIntyre, Joseph Muniz e Nadhem Alfarhan (puoi scaricare una parte del libro seguendo il link). Hai tre opzioni per raggiungere l'obiettivo: leggere l'intero libro, scorrerne il contenuto fermandoti ogni 10° o 20° pagina, o cercare un riassunto dei concetti chiave su qualche blog o servizio come SmartReading. La telemetria non campionata è come leggere ogni “pagina” del traffico di rete, ossia analizzare i metadati di ogni pacchetto. La telemetria campionata consiste nello studio selettivo del traffico nella speranza che nei campioni scelti trovi ciò che ti serve. A seconda della velocità del canale, la telemetria campionata restituirà per l'analisi ogni 64°, 200°, 500°, 1000°, 2000° o persino 10000° pacchetto.
Nel contesto del monitoraggio della sicurezza informatica, questo significa che la telemetria campionata è ben adatta per rilevare attacchi DDoS, scansioni e diffusione di malware, ma può perdere attacchi atomici o mult pacchetto che non rientrano nel campione inviato per analisi. La telemetria non campionata non presenta tali svantaggi e, grazie a essa, lo spettro degli attacchi rilevabili è molto più ampio. Ecco un breve elenco di eventi che possono essere rilevati utilizzando strumenti di analisi della telemetria di rete.
Naturalmente, un analizzatore Netflow open source non vi permetterà di fare ciò, poiché il suo obiettivo principale è raccogliere la telemetria e condurre un'analisi di base dal punto di vista IT. Per identificare le minacce alla sicurezza informatica basate su flow, è necessario dotare l'analizzatore di vari motori e algoritmi, che individueranno i problemi di cybersicurezza basandosi su campi standard o personalizzati di Netflow, arricchendo i dati standard con informazioni provenienti da diverse fonti di Threat Intelligence, ecc.
Quindi, se avete la possibilità di scegliere, optate per Netflow o IPFIX. Ma anche se il vostro hardware funziona solo con sFlow, come nel caso dei produttori locali, potete comunque trarne vantaggio nel contesto della sicurezza.
Nell'estate del 2019, ho condotto un'analisi delle capacità offerte dai produttori russi di hardware di rete e tutti, ad eccezione di NSG, Poligon e Kraftway, dichiaravano supporto per sFlow (almeno Zelax, Natex, Eltex, QTech, Rusteletech).
La prossima domanda che vi si presenterà è: dove implementare il supporto per il flow a scopi di sicurezza? In realtà, la domanda non è formulata nel modo corretto. Su hardware moderno, il supporto per i protocolli flow è praticamente sempre presente. Quindi, riformulerei la domanda in questo modo: dove è più efficiente raccogliere la telemetria in termini di sicurezza? La risposta sarà abbastanza ovvia: a livello di accesso, dove vedrete il 100% di tutto il traffico, dove avrete informazioni dettagliate sulle macchine (MAC, VLAN, ID dell'interfaccia), dove potrete monitorare anche il traffico P2P tra le macchine, che è fondamentale per rilevare la scansione e la diffusione di codice malevolo. A livello di core, parte del traffico potrebbe non essere visibile, e a livello di perimetro vedrete, a malapena, un quarto del vostro traffico di rete totale. Ma se per qualche motivo nella vostra rete si sono insediati dispositivi esterni che consentono agli aggressori di 'entrare e uscire', bypassando il perimetro, allora l'analisi della telemetria da lì non vi sarà di alcun aiuto. Pertanto, per una copertura massima, è consigliabile attivare la raccolta della telemetria proprio a livello di accesso. Va notato che, anche se parliamo di virtualizzazione o container, nei moderni switch virtuali è spesso presente il supporto per il flow, il che consente di controllare il traffico anche lì.
Ma dato che ho sollevato il tema, è necessario rispondere alla domanda: cosa succede se l'hardware, fisico o virtuale, non supporta i protocolli di flow? O se il loro utilizzo è vietato (ad esempio, nei segmenti industriali per garantire l'affidabilità)? O se il loro attivazione porta a un elevato carico della CPU (può succedere su hardware obsoleto)? Per affrontare questo problema, esistono sensori virtuali specializzati (flow sensor), che sono in sostanza normali diramatori che fanno passare il traffico e lo trasmettono in forma di flow al modulo di raccolta. Tuttavia, in questo caso ci troviamo di fronte a un insieme di problemi, come abbiamo discusso in precedenza riguardo ai mezzi di cattura dei pacchetti. Vale a dire, è importante comprendere non solo i vantaggi della tecnologia di analisi dei flussi, ma anche le sue limitazioni.
Un altro aspetto da tenere a mente quando si parla degli strumenti di analisi del flusso. Se per gli strumenti di generazione eventi di sicurezza utilizziamo la metrica EPS (eventi al secondo), per l'analisi della telemetria questa metrica non è applicabile; viene sostituita da FPS (flussi al secondo). Come nel caso dell'EPS, non è possibile calcolarlo in anticipo, ma si può stimare il numero approssimativo di flussi generati da un determinato dispositivo in base al suo compito. Online puoi trovare tabelle con valori indicativi per diversi tipi di dispositivi aziendali che ti permetteranno di stimare quali licenze sono necessarie per gli strumenti di analisi e quale sarà la loro architettura. Il fatto è che il sensore IDS è limitato da una certa larghezza di banda che può "sostenere", e anche il collettore di flussi ha delle limitazioni che bisogna comprendere. Pertanto, nelle reti grandi e geograficamente distribuite, ci sono solitamente più collettori. Quando ho descritto, , ho già menzionato il numero dei nostri collezionisti - sono 21. E questo per una rete dispersa su cinque continenti e che conta circa mezzo milione di dispositivi attivi).
Come sistema di monitoraggio Netflow, utilizziamo la nostra soluzione proprietaria , progettato specificamente per affrontare le questioni di sicurezza. Dispone di diversi motori integrati per rilevare attività anomale, sospette e manifestamente malevole, consentendo di identificare un'ampia gamma di minacce diverse — dal crypto-mining alle perdite di dati, dalla diffusione di malware alle frodi. Come la maggior parte dei flussometri, Stealthwatch è basato su uno schema a tre livelli (generatore — raccoglitore — analizzatore), ma è arricchito da una serie di caratteristiche interessanti, rilevanti nel contesto trattato. Innanzitutto, si integra con soluzioni di cattura dei pacchetti (ad esempio, Cisco Security Packet Analyzer), che consente di registrare sessioni di rete selezionate per un successivo approfondito esame e analisi. In secondo luogo, abbiamo sviluppato un protocollo speciale, nvzFlow, specificamente per ampliare le capacità di sicurezza, che permette di 'trasmettere' l'attività delle applicazioni sugli endpoint (server, workstation, ecc.) in telemetria e trasferirla al raccoglitore per l'analisi successiva. Se nella sua variante originale Stealthwatch lavora con qualsiasi protocollo di flusso (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) a livello di rete, il supporto per nvzFlow consente di effettuare la correlazione dei dati anche a livello di nodo, aumentando così l'efficacia dell'intero sistema e identificando più attacchi rispetto ai normali analizzatori di flusso di rete.
È evidente che parlando di sistemi di analisi Netflow in termini di sicurezza, il mercato non è limitato a una sola soluzione di Cisco. Puoi utilizzare sia soluzioni commerciali che gratuite o a pagamento parziale. È piuttosto strano se nel blog di Cisco citassi esempi di soluzioni concorrenti, quindi dirò qualche parola su come la telemetria di rete può essere analizzata usando due strumenti popolari, simili nel nome, ma comunque diversi: SiLK ed ELK.
SiLK è un insieme di strumenti (the System for Internet-Level Knowledge) per l'analisi del traffico, sviluppato dal CERT/CC americano e che supporta, nel contesto di questo articolo, Netflow (versioni 5 e 9, le più popolari), IPFIX e sFlow, e attraverso varie utilità (rwfilter, rwcount, rwflowpack, ecc.) eseguire diverse operazioni sulla telemetria di rete per rilevare segni di attività non autorizzate. Ma è importante notare un paio di punti fondamentali. SiLK è uno strumento da riga di comando e l'analisi operativa richiede di inserire continuamente comandi del tipo (rilevamento di pacchetti ICMP superiori 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 usare l'interfaccia grafica iSiLK, ma non semplificherà molto la tua vita, risolvendo solo la funzione di visualizzazione, e non quella di analisi. E questo è il secondo punto. A differenza delle soluzioni commerciali, che già includono una solida base analitica, algoritmi per la rilevazione delle anomalie, workflow corrispondenti, ecc., nel caso di SiLK dovrai fare tutto questo da solo, il che richiederà competenze 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 loro ti aiutino in questo (gli strumenti commerciali sono meno dipendenti dalle competenze degli utenti, anche se si presume comunque che gli analisti comprendano almeno le basi delle indagini e del monitoraggio di rete). Ma torniamo a SiLK. Il ciclo di lavoro di un analista con esso appare nel seguente modo:
- Formulazione dell'ipotesi. Dobbiamo comprendere cosa stiamo cercando all'interno della telemetria di rete, conoscere le caratteristiche uniche mediante le quali identificheremo determinate anomalie o minacce.
- Costruzione del modello. Dopo aver formulato l'ipotesi, la programmiamo utilizzando Python, shell o altri strumenti che non appartengono a SiLK.
- Test. Arriva il momento di verificare la correttezza della nostra ipotesi, che viene confermata o smentita con l'ausilio degli strumenti SiLK, che iniziano con 'rw', 'set', 'bag'.
- Analisi dei dati reali. In un contesto industriale, SiLK ci aiuta a identificare qualcosa e l'analista deve rispondere a domande come "Abbiamo trovato ciò che prevedevamo?", "Questo corrisponde alla nostra ipotesi?", "Come ridurre il numero di falsi positivi?", "Come migliorare il tasso di riconoscimento?" e così via.
- Miglioramento. Nell'ultima fase, miglioriamo quanto fatto in precedenza: creiamo modelli, ottimizziamo il codice, riformuliamo e perfezioniamo l'ipotesi, e altro.
Questo ciclo sarà applicabile anche a Cisco Stealthwatch, ma quest'ultimo automatizza al massimo questi cinque passaggi, riducendo il numero di errori dell'analista e migliorando la tempestività nella rilevazione degli incidenti. Ad esempio, in SiLK puoi arricchire le statistiche di rete con dati esterni su IP dannosi 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 c'è interazione con indirizzi IP in blacklist.
Salendo nella piramide dei software di analisi dei flow, al SiLK completamente gratuito segue l'ELK, che è condizionatamente gratuito ed è 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 tutto deve essere scritto da zero, l'ELK dispone già di 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 (questa è una funzione integrata anche in Stealthwatch).
ELK ha anche una comunità piuttosto ampia che aggiunge 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 Logstash Netflow Module, che supporta solo Netflow.
Offrendo maggiore rapidità nella raccolta dei flussi e nella loro ricerca, attualmente ELK manca di un'analisi ricca e integrata per l'individuazione di anomalie e minacce nella telemetria di rete. In altre parole, seguendo il ciclo di vita descritto sopra, sarà necessario descrivere da soli i modelli di violazione e poi utilizzarli nel sistema operativo (non ci sono modelli predefiniti).
Ci sono ovviamente estensioni più avanzate per ELK che includono già alcuni modelli di rilevamento delle anomalie nella telemetria di rete, ma queste estensioni richiedono un investimento e a questo punto si pone la questione se ne valga la pena: scrivere un modello simile da soli, acquistare la sua implementazione per il proprio strumento di monitoraggio o optare per una soluzione pronta della classe Network Traffic Analysis.
Non voglio entrare in polemica sul fatto che sia meglio spendere soldi per un sistema di monitoraggio delle anomalie e delle minacce nella telemetria di rete (come Cisco Stealthwatch) o capire come gestire da soli e adattare strumenti come SiLK, ELK, nfdump o OSU Flow Tools a ogni nuova minaccia (riferendomi agli ultimi due). Ogni persona fa la propria scelta e ha i suoi motivi per optare per una delle due opzioni. Io volevo semplicemente mostrare che la telemetria di rete è uno strumento molto importante per garantire la sicurezza della propria infrastruttura interna e non dovrebbe essere trascurato, per evitare di unirsi alla lista di aziende il cui nome viene citato nei media insieme a epiteti come 'hackerata', 'che non rispettano i requisiti di sicurezza informatica', 'che non si preoccupano della sicurezza dei propri dati e di quelli dei clienti'.
In conclusione, vorrei elencare i principali consigli da seguire nell'implementazione del monitoraggio della sicurezza informatica della propria infrastruttura interna:
- Non limitarti al perimetro! Utilizza (e scegli) l'infrastruttura di rete non solo per trasmettere traffico da punto A a punto B, ma anche per affrontare le questioni di cybersicurezza.
- Esplora i meccanismi di monitoraggio della sicurezza informatica nel tuo hardware di rete e attivali.
- Per il monitoraggio interno, preferisci l'analisi della telemetria: permette di rilevare fino all'80-90% di tutti gli incidenti informatici nella rete, realizzando ciò che non è possibile con la cattura dei pacchetti di rete e risparmiando spazio per memorizzare tutti gli eventi di sicurezza.
- Per il monitoraggio dei flussi, utilizza Netflow v9 o IPFIX: offrono maggiori informazioni nel contesto della sicurezza e consentono di monitorare non solo IPv4, ma anche IPv6, MPLS, ecc.
- Utilizza un protocollo di flusso non campionato: fornisce maggiori informazioni per la rilevazione delle minacce. Ad esempio, Netflow o IPFIX.
- Controlla il carico del tuo hardware di rete: potrebbe non essere in grado di gestire anche il protocollo di flusso. In tal caso, considera l'uso di sensori virtuali o di un'unità di generazione Netflow.
- Implementa il controllo innanzitutto a livello di accesso: ti permetterà di vedere il 100% di tutto il traffico.
- Se non avete scelta e utilizzate apparecchiature di rete russe, scegliete quelle che supportano i protocolli di flow o che hanno porte SPAN/RSPAN.
- Combinare i sistemi di rilevamento/prevenzione delle intrusioni/attacchi ai confini con i sistemi di analisi del traffico nella rete interna (compresi i cloud).
Per quanto riguarda l'ultimo consiglio, vorrei fornire un'illustrazione che ho già presentato in precedenza. Vedete che, mentre in passato il servizio di sicurezza informatica Cisco costruiva quasi interamente il proprio sistema di monitoraggio della sicurezza informatica basandosi su sistemi di rilevamento delle intrusioni e metodi basati su firme, ora rappresentano solo il 20% degli incidenti. Un altro 20% riguarda i sistemi di analisi del traffico, il che indica che queste soluzioni non sono un capriccio, ma strumenti reali per le attività dei servizi di sicurezza informatica nelle moderne imprese. Inoltre, avete a disposizione ciò che è più importante per la loro implementazione: l'infrastruttura di rete, il cui investimento può essere ulteriormente protetto, affidando alla rete anche le funzioni di monitoraggio della sicurezza informatica.
Non ho trattato specificamente il tema della risposta alle anomalie o alle minacce rilevate nei flussi di rete, ma credo sia chiaro che il monitoraggio non deve fermarsi solo alla scoperta di una minaccia. Deve seguire una risposta, e preferibilmente in modo automatico o automatizzato. Ma questo è già oggetto di un altro materiale.
Informazioni aggiuntive:
P.S. Se ti è più facile comprendere a voce quanto scritto sopra, puoi guardare una presentazione di un'ora che ha costituito la base di questa nota.
Fonte: habr.com
