Quando si tratta di monitorare la sicurezza di una rete interna aziendale o dipartimentale, molti lo associano al controllo delle fughe di informazioni e all’implementazione di soluzioni DLP. E se provi a chiarire la domanda e chiedi come rilevare gli attacchi alla rete interna, la risposta, di regola, menzionerà i sistemi di rilevamento delle intrusioni (IDS). E quella che 10-20 anni fa era l’unica opzione, oggi sta diventando un anacronismo. Esiste un'opzione più efficace e, in alcuni luoghi, l'unica possibile per monitorare una rete interna: utilizzare i protocolli di flusso, originariamente progettati per cercare problemi di rete (risoluzione dei problemi), ma col tempo trasformati in uno strumento di sicurezza molto interessante. Parleremo di quali protocolli di flusso esistono e quali sono migliori nel rilevare gli attacchi di rete, dove è meglio implementare il monitoraggio del flusso, cosa cercare quando si implementa un tale schema e anche come "sollevare" tutto questo sulle apparecchiature domestiche nell'ambito di questo articolo.
Non mi soffermerò sulla domanda "Perché è necessario il monitoraggio della sicurezza dell'infrastruttura interna?" La risposta sembra essere chiara. Ma se vuoi comunque assicurarti ancora una volta che oggi non potrai più farne a meno, un breve video su come penetrare in 17 modi in una rete aziendale protetta da firewall. Partiremo quindi dal presupposto di aver compreso che il monitoraggio interno è una cosa necessaria e non resta che capire come può essere organizzato.
Vorrei evidenziare tre fonti di dati chiave per il monitoraggio dell'infrastruttura a livello di rete:
- traffico “grezzo” che acquisiamo e sottoponiamo per l'analisi a determinati sistemi di analisi,
- eventi provenienti dai dispositivi di rete attraverso i quali passa il traffico,
- informazioni sul traffico ricevute tramite uno dei protocolli di flusso.
L'acquisizione del traffico non elaborato è l'opzione più popolare tra gli specialisti della sicurezza, perché storicamente è apparsa ed è stata la prima. I sistemi convenzionali di rilevamento delle intrusioni di rete (il primo vero sistema di rilevamento delle intrusioni commerciale è stato NetRanger del gruppo Wheel, acquistato nel 1998 da Cisco) erano proprio impegnati nella cattura di pacchetti (e successive sessioni) in cui si cercavano determinate firme ("regole decisive" in terminologia FSTEC), segnalazione di attacchi. Naturalmente, è possibile analizzare il traffico non elaborato non solo utilizzando IDS, ma anche utilizzando altri strumenti (ad esempio Wireshark, tcpdum o la funzionalità NBAR2 in Cisco IOS), ma di solito mancano della base di conoscenza che distingue uno strumento di sicurezza delle informazioni da un normale Strumento informatico.
Quindi, attacca i sistemi di rilevamento. Il metodo più antico e popolare per rilevare gli attacchi di rete, che svolge un buon lavoro a livello perimetrale (non importa quale: azienda, data center, segmento, ecc.), ma fallisce nelle moderne reti commutate e definite dal software. Nel caso di una rete costruita sulla base di switch convenzionali, l'infrastruttura dei sensori di rilevamento degli attacchi diventa troppo grande: sarà necessario installare un sensore su ogni connessione al nodo su cui si desidera monitorare gli attacchi. Qualsiasi produttore, ovviamente, sarà felice di venderti centinaia e migliaia di sensori, ma penso che il tuo budget non possa sostenere tali spese. Posso dire che anche in Cisco (e siamo gli sviluppatori di NGIPS) non potremmo farlo, anche se sembrerebbe che la questione del prezzo sia davanti a noi. Non dovrei sopportare: è una nostra decisione. Inoltre, sorge la domanda: come collegare il sensore in questa versione? Nel divario? Cosa succede se il sensore stesso si guasta? Richiedi un modulo bypass nel sensore? Utilizzare i divisori (tocco)? Tutto ciò rende la soluzione più costosa e la rende inaccessibile per un’azienda di qualsiasi dimensione.
Puoi provare a "sospendere" il sensore su una porta SPAN/RSPAN/ERSPAN e indirizzare il traffico dalle porte dello switch richieste ad essa. Questa opzione rimuove parzialmente il problema descritto nel paragrafo precedente, ma ne pone un altro: la porta SPAN non può accettare assolutamente tutto il traffico che le verrà inviato, non avrà larghezza di banda sufficiente. Dovrai sacrificare qualcosa. Lasciare alcuni nodi senza monitoraggio (quindi è necessario prima dare loro la priorità) oppure inviare non tutto il traffico dal nodo, ma solo un certo tipo. In ogni caso, potremmo perdere alcuni attacchi. Inoltre la porta SPAN può essere utilizzata per altre esigenze. Di conseguenza, dovremo rivedere la topologia della rete esistente ed eventualmente apportarvi modifiche per coprire al massimo la vostra rete con il numero di sensori di cui disponete (e coordinarlo con l'IT).
Cosa succede se la tua rete utilizza percorsi asimmetrici? Cosa succede se hai implementato o prevedi di implementare SDN? Cosa succede se hai bisogno di monitorare macchine o container virtualizzati il cui traffico non raggiunge affatto lo switch fisico? Queste sono domande che i venditori IDS tradizionali non apprezzano perché non sanno come rispondere. Forse ti convinceranno che tutte queste tecnologie alla moda sono una montatura e non ne hai bisogno. Forse parleranno della necessità di iniziare in piccolo. O forse diranno che è necessario mettere un potente trebbiatore al centro della rete e indirizzarvi tutto il traffico utilizzando i bilanciatori. Qualunque sia l'opzione che ti viene offerta, devi capire chiaramente come ti si addice. E solo dopo decidere sulla scelta di un approccio al monitoraggio della sicurezza delle informazioni dell'infrastruttura di rete. Tornando alla cattura dei pacchetti, voglio dire che questo metodo continua ad essere molto popolare e importante, ma il suo scopo principale è il controllo delle frontiere; confini tra la vostra organizzazione e Internet, confini tra il data center e il resto della rete, confini tra il sistema di controllo dei processi e il segmento aziendale. In questi luoghi, gli IDS/IPS classici hanno ancora il diritto di esistere e di svolgere bene i propri compiti.
Passiamo alla seconda opzione. L'analisi degli eventi provenienti dai dispositivi di rete può essere utilizzata anche per il rilevamento degli attacchi, ma non come meccanismo principale, poiché consente di rilevare solo una piccola classe di intrusioni. Inoltre, è inerente ad una certa reattività: l'attacco deve prima verificarsi, quindi deve essere registrato da un dispositivo di rete, che in un modo o nell'altro segnalerà un problema con la sicurezza delle informazioni. Esistono molti modi simili. Potrebbe essere syslog, RMON o SNMP. Gli ultimi due protocolli per il monitoraggio della rete nel contesto della sicurezza informatica vengono utilizzati solo se dobbiamo rilevare un attacco DoS alle apparecchiature di rete stesse, poiché utilizzando RMON e SNMP è possibile, ad esempio, monitorare il carico sulla centrale del dispositivo processore o le sue interfacce. Questo è uno dei "più economici" (tutti hanno syslog o SNMP), ma anche il più inefficace di tutti i metodi per monitorare la sicurezza delle informazioni dell'infrastruttura interna: molti attacchi gli vengono semplicemente nascosti. Naturalmente, non vanno trascurati, e la stessa analisi syslog aiuta a identificare tempestivamente i cambiamenti nella configurazione del dispositivo stesso, la sua compromissione, ma non è molto adatta per rilevare attacchi all'intera rete.
La terza opzione consiste nell'analizzare le informazioni sul traffico che passa attraverso un dispositivo che supporta uno dei numerosi protocolli di flusso. In questo caso, indipendentemente dal protocollo, l’infrastruttura di threading è necessariamente composta da tre componenti:
- Generazione o esportazione del flusso. Questo ruolo viene solitamente assegnato a un router, uno switch o un altro dispositivo di rete che, facendo passare attraverso se stesso il traffico di rete, consente di estrarne parametri chiave, che vengono poi trasmessi al modulo di raccolta. Cisco, ad esempio, supporta il protocollo Netflow non solo su router e switch, anche virtuali e industriali, ma anche su controller wireless, firewall e persino server.
- Flusso di raccolta. Considerando che una rete moderna è solitamente dotata di più apparati di rete, si pone il problema della raccolta e del consolidamento dei flussi, che viene risolto utilizzando i cosiddetti collettori, che elaborano i flussi ricevuti e poi li trasmettono per l'analisi.
- Analisi del flusso L'analizzatore assume il compito intellettuale principale e, applicando vari algoritmi ai flussi, trae alcune conclusioni. Un analizzatore di questo tipo può ad esempio identificare i colli di bottiglia della rete nell'ambito di una funzione IT o analizzare il profilo del carico del traffico per un'ulteriore ottimizzazione della rete. E per la sicurezza delle informazioni, un analizzatore di questo tipo può rilevare fughe di dati, diffusione di codici dannosi o attacchi DoS.
Non pensare che questa architettura a tre livelli sia troppo complicata: anche tutte le altre opzioni (tranne, forse, i sistemi di monitoraggio della rete che funzionano con SNMP e RMON) funzionano in base ad essa. Disponiamo di un generatore di dati per l'analisi, che può essere un dispositivo di rete o un sensore autonomo. Disponiamo di un sistema di raccolta allarmi e di un sistema di gestione dell'intera infrastruttura di monitoraggio. Gli ultimi due componenti possono essere combinati all'interno di un unico nodo, ma in reti 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 sullo studio dell'intestazione e dei dati del corpo di ciascun pacchetto e delle sessioni che lo compongono, l'analisi del flusso 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 utilizzando diversi protocolli di flusso. Inizialmente venivano utilizzati per analizzare statistiche e individuare problemi IT sulla rete, ma poi, con lo sviluppo dei meccanismi analitici, è diventato possibile applicarli alla stessa telemetria per scopi di sicurezza. Vale la pena notare ancora una volta che l'analisi del flusso non sostituisce né sostituisce l'acquisizione dei pacchetti. Ciascuno di questi metodi ha il proprio campo di applicazione. Ma nel contesto di questo articolo, è l’analisi del flusso la più adatta per monitorare l’infrastruttura interna. Ci sono dispositivi di rete (indipendentemente dal fatto che operino secondo un paradigma definito dal software o secondo regole statiche) che un attacco non può aggirare. Può bypassare un classico sensore IDS, ma un dispositivo di rete che supporta il protocollo di flusso non può farlo. Questo è il vantaggio di questo metodo.
D'altra parte, se hai bisogno di prove per le forze dell'ordine o per la tua squadra investigativa sugli incidenti, non puoi fare a meno dell'acquisizione dei pacchetti: la telemetria di rete non è una copia del traffico che può essere utilizzata per raccogliere prove; è necessario per un rilevamento rapido e un processo decisionale nel campo della sicurezza delle informazioni. D'altronde, utilizzando l'analisi telemetrica, è possibile “scrivere” non tutto il traffico di rete (semmai Cisco si occupa dei data center :-), ma solo quello coinvolto nell'attacco. Gli strumenti di analisi della telemetria a questo riguardo integreranno bene i tradizionali meccanismi di acquisizione dei pacchetti, fornendo comandi per l'acquisizione e l'archiviazione selettiva. Altrimenti, dovrai disporre di un'infrastruttura di archiviazione colossale.
Immaginiamo una rete che funzioni alla velocità di 250 Mbit/sec. Se desideri archiviare tutto questo volume, avrai bisogno di 31 MB di spazio di archiviazione per un secondo di trasmissione del traffico, 1,8 GB per un minuto, 108 GB per un'ora e 2,6 TB per un giorno. Per archiviare i dati giornalieri da una rete con una larghezza di banda di 10 Gbit/s, avrai bisogno di 108 TB di spazio di archiviazione. Ma alcuni enti regolatori richiedono la conservazione dei dati di sicurezza per anni... La registrazione su richiesta, che l'analisi del flusso aiuta a implementare, aiuta a ridurre questi valori di ordini di grandezza. A proposito, se parliamo del rapporto tra il volume dei dati di telemetria di rete registrati e l'acquisizione completa dei dati, allora è di circa 1 a 500. Per gli stessi valori sopra indicati, viene memorizzata una trascrizione completa di tutto il traffico giornaliero saranno rispettivamente 5 e 216 GB (puoi anche registrarlo su una normale unità flash).
Se per gli strumenti per l'analisi dei dati grezzi della rete, il metodo per acquisirli è quasi lo stesso da fornitore a fornitore, nel caso dell'analisi del flusso la situazione è diversa. Esistono diverse opzioni per i protocolli di flusso, le cui differenze è necessario conoscere nel contesto della sicurezza. Il più popolare è il protocollo Netflow sviluppato da Cisco. Esistono diverse versioni di questo protocollo, che differiscono per le capacità e la quantità di informazioni sul traffico registrate. La versione attuale è la nona (Netflow v9), sulla base della quale è stato sviluppato lo standard industriale Netflow v10, noto anche come IPFIX. Oggi, la maggior parte dei fornitori di reti supporta Netflow o IPFIX nelle proprie apparecchiature. Ma ci sono varie altre opzioni per i protocolli di flusso: sFlow, jFlow, cFlow, rFlow, NetStream, ecc., di cui sFlow è il più popolare. È questo tipo che viene spesso supportato dai produttori nazionali di apparecchiature di rete grazie alla sua facilità di implementazione. Quali sono le differenze principali tra Netflow, che è diventato uno standard de facto, e sFlow? Ne metterei in evidenza alcuni fondamentali. Innanzitutto, Netflow dispone di campi personalizzabili dall'utente rispetto ai campi fissi in sFlow. In secondo luogo, e questa è la cosa più importante nel nostro caso, sFlow raccoglie la cosiddetta telemetria campionata; a differenza di quello non campionato per Netflow e IPFIX. Qual'è la differenza tra loro?
Immagina di decidere di leggere il libro”" dei miei colleghi - Gary McIntyre, Joseph Munitz e Nadem Alfardan (puoi scaricare parte del libro dal link). Hai tre opzioni per raggiungere il tuo obiettivo: leggere l'intero libro, sfogliarlo, fermandoti a ogni 10 o 20 pagine o provare a trovare una rivisitazione dei concetti chiave su un blog o un servizio come SmartReading. Pertanto, la telemetria non campionata legge ogni “pagina” del traffico di rete, ovvero analizza i metadati per ciascun pacchetto. La telemetria campionata è lo studio selettivo del traffico nella speranza che i campioni selezionati contengano ciò di cui hai bisogno. A seconda della velocità del canale, la telemetria campionata verrà inviata per l'analisi ogni 64esimo, 200esimo, 500esimo, 1000esimo, 2000esimo o anche 10000esimo pacchetto.
Nel contesto del monitoraggio della sicurezza delle informazioni, ciò significa che la telemetria campionata è particolarmente adatta per rilevare attacchi DDoS, scansione e diffusione di codice dannoso, ma potrebbe non rilevare attacchi atomici o multipacchetto che non erano inclusi nel campione inviato per l'analisi. La telemetria non campionata non presenta tali svantaggi. In questo modo, la gamma degli attacchi rilevati è molto più ampia. Di seguito è riportato un breve elenco di eventi che possono essere rilevati utilizzando gli strumenti di analisi della telemetria di rete.
Naturalmente, alcuni analizzatori Netflow open source non ti consentiranno di farlo, poiché il suo compito principale è raccogliere dati di telemetria e condurre analisi di base su di essi da un punto di vista IT. Per identificare le minacce alla sicurezza delle informazioni in base al flusso, è necessario dotare l'analizzatore di vari motori e algoritmi, che identificheranno i problemi di sicurezza informatica sulla base di campi Netflow standard o personalizzati, arricchiranno i dati standard con dati esterni provenienti da varie fonti di Threat Intelligence, ecc.
Pertanto, se puoi scegliere, scegli Netflow o IPFIX. Ma anche se i vostri apparecchi funzionano solo con sFlow, come i produttori nazionali, allora anche in questo caso potrete trarne vantaggio in un contesto di sicurezza.
Nell'estate del 2019, ho analizzato le capacità dei produttori di hardware di rete russi e tutti, esclusi NSG, Polygon e Craftway, hanno annunciato il supporto per sFlow (almeno Zelax, Natex, Eltex, QTech, Rusteleteh).
La prossima domanda che dovrai affrontare è: dove implementare il supporto del flusso per motivi di sicurezza? In realtà la domanda non è posta del tutto correttamente. Le apparecchiature moderne supportano quasi sempre i protocolli di flusso. Pertanto, riformulerei la domanda in modo diverso: dov'è più efficace raccogliere dati di telemetria dal punto di vista della sicurezza? La risposta sarà abbastanza ovvia: a livello di accesso, dove vedrai il 100% di tutto il traffico, dove avrai informazioni dettagliate sugli host (MAC, VLAN, ID interfaccia), dove potrai persino monitorare il traffico P2P tra host, che è fondamentale per la scansione, il rilevamento e la distribuzione di codice dannoso. A livello centrale, potresti semplicemente non vedere parte del traffico, ma a livello perimetrale vedrai un quarto di tutto il traffico di rete. Ma se per qualche motivo sulla tua rete sono presenti dispositivi estranei che consentono agli aggressori di "entrare e uscire" senza aggirare il perimetro, l'analisi della telemetria da esso non ti darà nulla. Pertanto, per la massima copertura, si consiglia di abilitare la raccolta di telemetria a livello di accesso. Allo stesso tempo, vale la pena notare che anche se parliamo di virtualizzazione o container, nei moderni switch virtuali si trova spesso il supporto del flusso, che consente di controllare il traffico anche lì.
Ma poiché ho sollevato l’argomento, devo rispondere alla domanda: cosa succede se l’apparecchiatura, fisica o virtuale, non supporta i protocolli di flusso? Oppure è vietata la sua inclusione (ad esempio nei segmenti industriali per garantirne l'affidabilità)? Oppure l'attivazione comporta un carico elevato della CPU (questo accade su hardware meno recente)? Per risolvere questo problema, esistono sensori virtuali specializzati (sensori di flusso), che sono essenzialmente normali splitter che fanno passare il traffico attraverso se stessi e lo trasmettono sotto forma di flusso al modulo di raccolta. È vero, in questo caso otteniamo tutti i problemi di cui abbiamo parlato sopra in relazione agli strumenti di acquisizione dei pacchetti. Cioè, è necessario comprendere non solo i vantaggi della tecnologia di analisi del flusso, ma anche i suoi limiti.
Un altro punto che è importante ricordare quando si parla di strumenti di analisi del flusso. Se in relazione ai mezzi convenzionali di generazione di eventi di sicurezza utilizziamo la metrica EPS (evento al secondo), allora questo indicatore non è applicabile all'analisi della telemetria; è sostituito da FPS (flusso al secondo). Come nel caso dell'EPS, non è possibile calcolarlo in anticipo, ma è possibile stimare il numero approssimativo di thread generati da un particolare dispositivo in base al suo compito. Puoi trovare tabelle su Internet con valori approssimativi per diversi tipi di dispositivi e condizioni 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ò “tirare”, e il collettore di flusso ha i suoi limiti che devono essere compresi. Pertanto, nelle reti grandi e geograficamente distribuite, di solito sono presenti diversi collettori. Quando ho descritto , ho già fornito il numero dei nostri collezionisti: sono 21. E questo per una rete sparsa in cinque continenti e che conta circa mezzo milione di dispositivi attivi).
Utilizziamo la nostra soluzione come sistema di monitoraggio Netflow , che è specificamente focalizzato sulla risoluzione dei problemi di sicurezza. Dispone di numerosi motori integrati per il rilevamento di attività anomale, sospette e chiaramente dannose, che consentono di rilevare un'ampia gamma di minacce diverse: dal cryptomining alle fughe di informazioni, dalla diffusione di codice dannoso alle frodi. Come la maggior parte degli analizzatori di flusso, Stealthwatch è costruito secondo uno schema a tre livelli (generatore - collettore - analizzatore), ma è integrato con una serie di caratteristiche interessanti che sono importanti nel contesto del materiale in esame. Innanzitutto, si integra con soluzioni di acquisizione dei pacchetti (come Cisco Security Packet Analyser), che consente di registrare sessioni di rete selezionate per successive indagini e analisi approfondite. In secondo luogo, appositamente per espandere le attività di sicurezza, abbiamo sviluppato uno speciale protocollo nvzFlow, che consente di "trasmettere" l'attività delle applicazioni sui nodi finali (server, workstation, ecc.) in telemetria e trasmetterla al collector per ulteriori analisi. Se nella sua versione originale Stealthwatch funziona con qualsiasi protocollo di flusso (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) a livello di rete, il supporto nvzFlow consente quindi la correlazione dei dati anche a livello di nodo. aumentando l'efficienza dell'intero sistema e riscontrando più attacchi rispetto ai tradizionali analizzatori di flusso di rete.
È chiaro che quando si parla di sistemi di analisi Netflow dal punto di vista della sicurezza, il mercato non si limita ad un'unica soluzione Cisco. Puoi utilizzare sia soluzioni commerciali che gratuite o shareware. È abbastanza strano se cito le soluzioni della concorrenza come esempi sul blog Cisco, quindi dirò alcune parole su come analizzare la telemetria di rete utilizzando due strumenti popolari, simili nel nome, ma comunque diversi: SiLK ed ELK.
SiLK è un insieme di strumenti (il System for Internet-Level Knowledge) per l'analisi del traffico, sviluppati dall'americano CERT/CC e che supporta, nel contesto dell'articolo di oggi, Netflow (5a e 9a, le versioni più diffuse), IPFIX e sFlow e utilizzando varie utilità (rwfilter, rwcount, rwflowpack, ecc.) per eseguire varie operazioni sulla telemetria della rete al fine di rilevare segni di azioni non autorizzate al suo interno. Ma ci sono un paio di punti importanti da notare. SiLK è uno strumento da riga di comando che esegue analisi in linea inserendo comandi come questo (rilevamento di pacchetti ICMP più grandi di 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 la GUI di iSiLK, ma non ti renderà la vita molto più semplice, risolvendo solo la funzione di visualizzazione e non sostituendo l'analista. E questo è il secondo punto. A differenza delle soluzioni commerciali, che hanno già una solida base analitica, algoritmi di rilevamento delle anomalie, flusso di lavoro corrispondente, ecc., nel caso di SiLK dovrai fare tutto questo da solo, il che richiederà da te competenze leggermente diverse rispetto all'utilizzo di soluzioni già pronte. strumenti da utilizzare. Questo non è né buono né cattivo: è una caratteristica di quasi tutti gli strumenti gratuiti che presuppone che tu sappia cosa fare, e ti aiuterà solo in questo (gli strumenti commerciali dipendono meno dalle competenze dei loro utenti, anche se presuppongono anche che gli analisti comprendano almeno le nozioni di base delle indagini e del monitoraggio della rete). Ma torniamo a SiLK. Il ciclo di lavoro dell’analista si presenta così:
- Formulare un'ipotesi. Dobbiamo capire cosa cercheremo all'interno della telemetria della rete, conoscere gli attributi unici con cui identificheremo determinate anomalie o minacce.
- Costruire un modello. Dopo aver formulato un'ipotesi, la programmiamo utilizzando lo stesso Python, shell o altri strumenti non inclusi in SiLK.
- Test. Ora tocca a verificare la correttezza della nostra ipotesi, che viene confermata o smentita utilizzando le utilità SiLK che iniziano con 'rw', 'set', 'bag'.
- Analisi dei dati reali. Nel funzionamento industriale, SiLK ci aiuta a identificare qualcosa e l’analista deve rispondere alle domande “Abbiamo trovato quello che ci aspettavamo?”, “Questo corrisponde alla nostra ipotesi?”, “Come ridurre il numero di falsi positivi?”, “Come migliorare il livello di riconoscimento?» e così via.
- Miglioramento. Nella fase finale, miglioriamo ciò che è stato fatto in precedenza: creiamo modelli, miglioriamo e ottimizziamo il codice, riformuliamo e chiariamo l'ipotesi, ecc.
Questo ciclo sarà applicabile anche a Cisco Stealthwatch, solo che l'ultimo automatizza al massimo questi cinque passaggi, riducendo il numero di errori degli analisti e aumentando l'efficienza del rilevamento degli incidenti. Ad esempio, in SiLK è possibile arricchire le statistiche di rete con dati esterni su IP dannosi utilizzando script scritti a mano, e in Cisco Stealthwatch è una funzione integrata che visualizza immediatamente un allarme se il traffico di rete contiene interazioni con indirizzi IP dalla lista nera.
Se si sale più in alto nella piramide “a pagamento” del software di analisi del flusso, dopo SiLK assolutamente gratuito ci sarà un ELK shareware, 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 devi scrivere tutto da solo, ELK ha già molte librerie/moduli già pronti (alcuni a pagamento, altri no) che automatizzano l'analisi della telemetria di rete. Ad esempio, il filtro GeoIP in Logstash ti consente di associare gli indirizzi IP monitorati alla loro posizione geografica (Stealthwatch ha questa funzionalità integrata).
ELK dispone inoltre di una comunità abbastanza ampia che sta completando i componenti mancanti per questa soluzione di monitoraggio. Ad esempio, per lavorare con Netflow, IPFIX e sFlow è possibile utilizzare il modulo , se non sei soddisfatto del modulo Logstash Netflow, che supporta solo Netflow.
Pur offrendo maggiore efficienza nella raccolta del flusso e nella ricerca al suo interno, ELK attualmente non dispone di analisi integrate avanzate per il rilevamento di anomalie e minacce nella telemetria di rete. Cioè, seguendo il ciclo di vita sopra descritto, dovrai descrivere in modo indipendente i modelli di violazione e quindi utilizzarli nel sistema di combattimento (non ci sono modelli integrati lì).
Esistono, ovviamente, estensioni più sofisticate per ELK, che contengono già alcuni modelli per il rilevamento di anomalie nella telemetria di rete, ma tali estensioni costano denaro e la domanda è se il gioco vale la candela: scrivi tu stesso un modello simile, acquista la sua implementazione per il tuo strumento di monitoraggio o acquista una soluzione già pronta del corso Analisi del traffico di rete.
In generale, non voglio entrare nel dibattito sul fatto che sia meglio spendere soldi e acquistare una soluzione già pronta per monitorare anomalie e minacce nella telemetria di rete (ad esempio Cisco Stealthwatch) o capirlo da soli e personalizzare lo stesso SiLK, ELK o nfdump o OSU Flow Tools per ogni nuova minaccia (sto parlando delle ultime due ultima volta)? Ognuno sceglie per se stesso e ognuno ha i propri motivi per scegliere una delle due opzioni. Volevo solo dimostrare che la telemetria di rete è uno strumento molto importante per garantire la sicurezza di rete della propria infrastruttura interna e non bisogna trascurarla, per non entrare nell'elenco delle aziende il cui nome è menzionato nei media insieme agli epiteti " hackerato”, “non conforme ai requisiti di sicurezza delle informazioni””, “non pensando alla sicurezza dei propri dati e dei dati dei clienti”.
Per riassumere, vorrei elencare i suggerimenti chiave che dovresti seguire quando crei il monitoraggio della sicurezza delle informazioni della tua infrastruttura interna:
- Non limitarti solo al perimetro! Utilizza (e scegli) l’infrastruttura di rete non solo per spostare il traffico dal punto A al punto B, ma anche per affrontare i problemi di sicurezza informatica.
- Studia i meccanismi di monitoraggio della sicurezza delle informazioni esistenti nelle tue apparecchiature di rete e usali.
- Per il monitoraggio interno, dare la preferenza all'analisi telemetrica: consente di rilevare fino all'80-90% di tutti gli incidenti relativi alla sicurezza delle informazioni di rete, facendo ciò che è impossibile quando si acquisiscono pacchetti di rete e risparmiando spazio per l'archiviazione di tutti gli eventi di sicurezza delle informazioni.
- Per monitorare i flussi, utilizza Netflow v9 o IPFIX: forniscono più informazioni in un contesto di sicurezza e consentono di monitorare non solo IPv4, ma anche IPv6, MPLS, ecc.
- Utilizza un protocollo di flusso non campionato: fornisce maggiori informazioni per il rilevamento delle minacce. Ad esempio, Netflow o IPFIX.
- Controlla il carico sulle tue apparecchiature di rete: potrebbero non essere in grado di gestire anche il protocollo di flusso. Quindi considera l'utilizzo di sensori virtuali o Netflow Generation Appliance.
- Implementa il controllo innanzitutto a livello di accesso: questo ti darà l'opportunità di vedere il 100% di tutto il traffico.
- Se non hai scelta e utilizzi apparecchiature di rete russe, scegline una che supporti i protocolli di flusso o disponga di porte SPAN/RSPAN.
- Combinare sistemi di rilevamento/prevenzione di intrusioni/attacchi ai margini e sistemi di analisi dei flussi nella rete interna (anche nel cloud).
Per quanto riguarda l’ultimo consiglio, vorrei fare un’illustrazione che ho già dato prima. Vedete che se prima il servizio di sicurezza informatica Cisco costruiva quasi interamente il proprio sistema di monitoraggio della sicurezza informatica sulla base di sistemi di rilevamento delle intrusioni e metodi di firma, ora rappresentano solo il 20% degli incidenti. Un altro 20% ricade sui sistemi di analisi dei flussi, il che suggerisce che queste soluzioni non sono un capriccio, ma un vero strumento nelle attività dei servizi di sicurezza delle informazioni di un'impresa moderna. Inoltre, hai la cosa più importante per la loro implementazione: l'infrastruttura di rete, i cui investimenti possono essere ulteriormente protetti assegnando alla rete funzioni di monitoraggio della sicurezza delle informazioni.
Nello specifico non ho toccato il tema della risposta ad anomalie o minacce individuate nei flussi di rete, ma penso che sia già chiaro che il monitoraggio non dovrebbe concludersi solo con il rilevamento di una minaccia. Dovrebbe essere seguito da una risposta e preferibilmente in modalità automatica o automatizzata. Ma questo è un argomento per un articolo separato.
Informazioni aggiuntive:
PS. Se è più facile per te ascoltare tutto ciò che è stato scritto sopra, puoi guardare la presentazione di un'ora che ha costituito la base di questa nota.
Fonte: habr.com