Quandu si tratta di monitorà a sicurità di una reta corporativa o dipartimentale interna, assai l'associu cù u cuntrollu di fughe di informazioni è l'implementazione di soluzioni DLP. E s'è vo pruvate à chjarificà a quistione è dumandate cumu si rileva attacchi à a reta interna, allura a risposta serà, in regula, una menzione di sistemi di rilevazione di intrusioni (IDS). E ciò chì era l'unica opzione 10-20 anni fà hè diventatu un anacronismu oghje. Ci hè una più efficace, è in certi lochi, l'unica opzione pussibule per u monitoraghju di una rete interna - utilizendu protokolli di flussu, chì sò stati urigginariamenti pensati per circà i prublemi di a rete (risoluzione di prublemi), ma cù u tempu trasfurmatu in un strumentu di sicurità assai interessante. Parleremu di quali protokolli di flussu ci sò è quali sò megliu à detectà attacchi di rete, induve hè megliu implementà u monitoraghju di u flussu, ciò chì cercà quandu implementà un tali schema, è ancu cumu "elevà" tuttu questu nantu à l'equipaggiu domesticu. in u scopu di stu articulu.
Ùn mi stenderaghju micca nantu à a quistione "Perchè hè necessariu u monitoraghju di a sicurità di l'infrastruttura interna?" A risposta pare esse chjara. Ma se, quantunque, vulete assicurà una volta di più chì oghje ùn pudete micca campà senza ellu, un brevi video nantu à cumu pudete penetrà una reta corporativa prutetta da un firewall in 17 manere. Dunque, assumeremu chì avemu capitu chì u monitoraghju internu hè una cosa necessaria è tuttu ciò chì resta hè di capisce cumu si pò esse urganizatu.
Puderia mette in risaltu trè fonti di dati chjave per u monitoraghju di l'infrastruttura à u livellu di a rete:
- trafficu "bruttu" chì catturamu è sottumettemu per analisi à certi sistemi di analisi,
- avvenimenti da i dispositi di rete attraversu u trafficu passa,
- infurmazione di trafficu ricevuta via unu di i protokolli di flussu.
A catturà u trafficu crudu hè l'opzione più populari trà i specialisti di sicurezza, perchè storicamente apparsu è era u primu. I sistemi di rilevazione di intrusioni di rete cunvinziunali (u primu sistema di rilevazione di intrusioni cummerciale era NetRanger da u Wheel Group, acquistatu in u 1998 da Cisco) sò stati precisamente impegnati in a catturazione di pacchetti (è di sessioni successive) in quale certe firme sò state cercate ("règuli decisive" in terminologia FSTEC), signaling attacks. Di sicuru, pudete analizà u trafficu crudu micca solu cù l'IDS, ma ancu aduprendu altre arnesi (per esempiu, Wireshark, tcpdum o a funziunalità NBAR2 in Cisco IOS), ma di solitu ùn mancanu a basa di cunniscenza chì distingue un strumentu di sicurità di l'infurmazioni da un rigulari. strumentu IT.
Dunque, sistemi di rilevazione di attaccu. U metudu più anticu è più populari di deteczione di attacchi di rete, chì faci un bonu travagliu in u perimetru (ùn importa ciò chì - corporativu, data center, segmentu, etc.), ma falla in e reti muderne cambiate è definite da software. In u casu di una reta custruita nantu à a basa di switches cunvinziunali, l'infrastruttura di sensori di deteczione d'attaccu diventa troppu grande - avete da installà un sensoru in ogni cunnessione à u node nantu à quale vulete monitorà l'attacchi. Qualchese fabricatore, sicuru, serà felice di vendevi centinaie è millaie di sensori, ma pensu chì u vostru budgetu ùn pò micca sustene tali spese. Puderaghju dì chì ancu in Cisco (è simu i sviluppatori di NGIPS) ùn pudemu micca fà questu, ancu se pare chì u prublema di u prezzu hè davanti à noi. Ùn deve micca stà - hè a nostra propria decisione. Inoltre, a quistione hè, cumu cunnette u sensoru in questa versione? In u spaziu? E se u sensoru stessu falla? Avete bisognu di un modulu di bypass in u sensoru? Aduprà splitters (tap)? Tuttu chistu rende a suluzione più caru è a rende inaccessibile per una cumpagnia di ogni dimensione.
Pudete pruvà à "impiccà" u sensoru nantu à un portu SPAN / RSPAN / ERSPAN è diretta u trafficu da i porti di commutazione necessarii. Questa opzione sguassate parzialmente u prublema descrittu in u paràgrafu precedente, ma pone un altru - u portu SPAN ùn pò micca accettà assolutamente tuttu u trafficu chì serà mandatu à ellu - ùn hà micca abbastanza larghezza di banda. Avete da sacrificà qualcosa. O lascià alcuni di i nodi senza monitoraghju (poi avete bisognu di priurità prima), o mandà micca tuttu u trafficu da u node, ma solu un certu tipu. In ogni casu, pudemu missu qualchi attacchi. Inoltre, u portu SPAN pò esse usatu per altri bisogni. In u risultatu, avemu da riviseghjà a topologia di a rete esistente è possibbilmente fà aghjustamenti per copre a vostra reta à u massimu cù u numeru di sensori chì avete (è coordinate questu cù IT).
E se a vostra reta usa rotte asimmetriche? E se avete implementatu o avete pianificatu di implementà SDN? E se avete bisognu di monitorà e macchine virtualizzate o cuntenituri chì u trafficu ùn ghjunghje micca in tuttu u cambiamentu fisicu? Quessi sò dumande chì i venditori tradiziunali di IDS ùn li piace micca perchè ùn sanu micca risponde. Forsi vi cunvinceranu chì tutte queste tecnulugia di moda sò hype è ùn avete micca bisognu. Forsi parlanu di a necessità di principià chjucu. O forsi anu da dì chì avete bisognu di mette un thresher putente à u centru di a reta è diretta tuttu u trafficu à questu utilizendu balancers. Qualunque sia l'opzione chì vi offre, avete bisognu di capisce chjaramente cumu vi cunvene. È solu dopu piglià una decisione nantu à a scelta di un accostu à u monitoraghju di a sicurità di l'infurmazioni di l'infrastruttura di a rete. Riturnà à a cattura di pacchetti, vogliu dì chì stu metudu cuntinueghja à esse assai populari è impurtante, ma u so scopu principale hè u cuntrollu di e fruntiere; cunfini trà a vostra urganizazione è Internet, cunfini trà u centru di dati è u restu di a reta, cunfini trà u sistema di cuntrollu di prucessu è u segmentu corporativu. In questi lochi, l'IDS / IPS classicu anu sempre u dirittu di esiste è di affruntà bè cù i so compiti.
Passemu à a seconda opzione. L'analisi di l'avvenimenti chì venenu da i dispositi di a rete pò ancu esse aduprata per scopi di deteczione d'attaccu, ma micca cum'è u mecanismu principale, postu chì permette di detectà solu una piccula classa di intrusioni. Inoltre, hè inherente à una certa reattività - l'attaccu deve esse prima, dopu deve esse registratu da un dispositivu di rete, chì in un modu o un altru signalà un prublema cù a sicurità di l'infurmazioni. Ci hè parechje manere cusì. Questu pò esse syslog, RMON o SNMP. L'ultimi dui protokolli per u monitoraghju di a rete in u cuntestu di a sicurità di l'infurmazioni sò usati solu s'ellu ci vole à detectà un attaccu DoS à l'equipaggiu di a rete stessu, postu chì cù RMON è SNMP hè pussibule, per esempiu, monitorà a carica in u centru di u dispusitivu. processore o e so interfacce. Questu hè unu di i "più prezzu" (tutti anu syslog o SNMP), ma ancu u più inefficace di tutti i metudi di monitorizà a sicurità di l'infurmazioni di l'infrastruttura interna - assai attacchi sò simpliciamente oculati da ellu. Di sicuru, ùn deve esse trascuratatu, è u listessu analisi syslog vi aiuta à identificà puntuale cambiamenti in a cunfigurazione di u dispusitivu stessu, u cumprumissu di questu, ma ùn hè micca assai adattatu per a deteczione di attacchi in tutta a reta.
A terza opzione hè di analizà l'infurmazioni nantu à u trafficu chì passa per un dispositivu chì sustene unu di parechji protokolli di flussu. In questu casu, indipendentemente da u protokollu, l'infrastruttura di threading hè necessariamente custituita da trè cumpunenti:
- Generazione o esportazione di flussu. Stu rolu hè di solitu attribuitu à un router, switch o un altru dispositivu di rete, chì, passendu u trafficu di a rete per ellu stessu, permette di estrae i paràmetri chjave da ellu, chì sò dopu trasmessi à u modulu di cullezzione. Per esempiu, Cisco sustene u protokollu Netflow micca solu in routers è switches, cumpresi virtuale è industriale, ma ancu in controller wireless, firewalls è ancu servitori.
- Flussu di cullezzione. In cunsiderà chì una reta muderna di solitu hà più di un dispositivu di rete, u prublema di cullizzioni è di cunsulidazione di i flussi nasce, chì hè risolta cù i cullettori chjamati, chì processanu i flussi ricevuti è poi trasmettenu per l'analisi.
- Analisi di flussu L'analizzatore assume u compitu intellettuale principale è, applicà diversi algoritmi à i flussi, tira certe cunclusioni. Per esempiu, cum'è parte di una funzione IT, un tali analizatore pò identificà i colli di bottiglia di a rete o analizà u prufilu di carica di trafficu per più ottimisazione di a rete. È per a sicurità di l'infurmazioni, un tali analizatore pò detectà fughe di dati, a diffusione di codice maliziusu o attacchi DoS.
Ùn pensate micca chì questa architettura di trè livelli hè troppu cumplicata - tutte l'altri opzioni (eccettu, forse, i sistemi di surviglianza di rete chì travaglianu cù SNMP è RMON) funzionanu ancu secondu. Avemu un generatore di dati per l'analisi, chì pò esse un dispositivu di rete o un sensoru stand-alone. Avemu un sistema di cullizzioni d'alarme è un sistema di gestione per tutta l'infrastruttura di monitoraghju. L'ultimi dui cumpunenti ponu esse cumminati in un unicu node, ma in più o menu grande rete sò generalmente spargugliati in almenu dui dispusitivi per assicurà a scalabilità è a affidabilità.
A cuntrariu di l'analisi di pacchetti, chì hè basatu annantu à studià l'intestazione è i dati di u corpu di ogni pacchettu è e sessioni in quale hè custituitu, l'analisi di flussu si basa in a cullizzioni di metadata nantu à u trafficu di a rete. Quandu, quantu, da induve è induve, cumu ... queste sò e dumande risposti da l'analisi di a telemetria di a rete utilizendu diversi protokolli di flussu. In principiu, sò stati usati per analizà e statistiche è truvà prublemi IT nantu à a reta, ma dopu, cum'è i miccanismi analitici sviluppati, hè diventatu pussibule di applicà à a listessa telemetria per scopi di sicurità. Hè da nutà dinò chì l'analisi di flussu ùn rimpiazza o rimpiazza a cattura di pacchetti. Ognunu di sti metudi hà a so propria area di applicazione. Ma in u cuntestu di questu articulu, hè l'analisi di flussu chì hè megliu adattatu per u monitoraghju di l'infrastruttura interna. Avete dispositi di rete (sia ch'elli operanu in un paradigma definitu da u software o secondu e regule statiche) chì un attaccu ùn pò micca bypass. Puderà passà un sensoru IDS classicu, ma un dispositivu di rete chì sustene u protocolu di flussu ùn pò micca. Questu hè u vantaghju di stu metudu.
Per d 'altra banda, sè avete bisognu di evidenza per l'applicazione di a lege o u vostru propiu squadra di investigazione di incidenti, ùn pudete micca fà senza cattura di pacchetti - a telemetria di a rete ùn hè micca una copia di u trafficu chì pò esse usata per cullà evidenza; hè necessariu per a rilevazione rapida è a decisione in u campu di a sicurità di l'infurmazioni. Per d 'altra banda, utilizendu l'analisi di telemetria, pudete "scrivite" micca tuttu u trafficu di a rete (se qualcosa, Cisco tratta di centri di dati :-), ma solu ciò chì hè implicatu in l'attaccu. Strumenti di analisi di telemetria in questu sensu cumplementanu bè i meccanismi tradiziunali di cattura di pacchetti, dendu cumandamenti per a cattura selettiva è u almacenamentu. Altrimenti, vi tuccherà à avè una infrastruttura di almacenamiento colossali.
Imaginemu una reta chì opera à una velocità di 250 Mbit/sec. Se vulete almacenà tuttu stu voluminu, avete bisognu di 31 MB di almacenamiento per una seconda di trasmissione di trafficu, 1,8 GB per un minutu, 108 GB per una ora, è 2,6 TB per un ghjornu. Per almacenà e dati di ogni ghjornu da una reta cù una larghezza di banda di 10 Gbit/s, avete bisognu di 108 TB di almacenamiento. Ma certi regulatori necessitanu di almacenà dati di sicurità per anni... A registrazione à a dumanda, chì l'analisi di flussu vi aiuta à implementà, aiuta à riduce questi valori per ordini di grandezza. In modu, se parlemu di u rapportu di u voluminu di dati di telemetria di a rete registrata è a captura di dati cumpleta, allora hè apprussimatamente 1 à 500. Per i stessi valori dati sopra, almacenà una trascrizione completa di tuttu u trafficu di ogni ghjornu. serà 5 è 216 GB, rispettivamente (pudete ancu registrà nantu à una unità flash regulare).
Se per l'uttene per l'analisi di e dati di a rete prima, u metudu di catturà hè quasi u stessu da u venditore à u venditore, allora in u casu di l'analisi di flussu a situazione hè diversa. Ci hè parechje opzioni per i protokolli di flussu, e differenze in quale avete bisognu di sapè in u cuntestu di sicurità. U più pupulare hè u protokollu Netflow sviluppatu da Cisco. Ci hè parechje versioni di stu protokollu, diffirenti in e so capacità è a quantità di infurmazione di trafficu arregistrata. A versione attuale hè a nona (Netflow v9), nantu à a basa di quale hè statu sviluppatu u standard di l'industria Netflow v10, cunnisciutu ancu IPFIX. Oghje, a maiò parte di i venditori di rete supportanu Netflow o IPFIX in u so equipamentu. Ma ci sò parechje altre opzioni per i protokolli di flussu - sFlow, jFlow, cFlow, rFlow, NetStream, etc., di quale sFlow hè u più populari. Hè stu tipu chì hè più spessu sustinutu da i fabricatori domestici di l'equipaggiu di rete per via di a so facilità di implementazione. Chì sò e differenzi chjave trà Netflow, chì hè diventatu un standard di facto, è sFlow? Puderaghju mette in risaltu parechji chjave. Prima, Netflow hà campi persunalizabili da l'utilizatori in uppusizione à i campi fissi in sFlow. E in segundu, è questu hè u più impurtante in u nostru casu, sFlow cullighja a telemetria sampled chjamata; in cuntrastu à quellu senza campionu per Netflow è IPFIX. Chì ci hè a diffarenza trà elli?
Imagine chì decide di leghje u libru "" di i mo culleghi - Gary McIntyre, Joseph Munitz è Nadem Alfardan (pudete scaricà una parte di u libru da u ligame). Avete trè opzioni per ghjunghje à u vostru scopu - leghjite u libru sanu, scorri à traversu, fermendu à ogni 10ª o 20ª pagina, o pruvate à truvà una ricuperazione di cuncetti chjave in un blog o serviziu cum'è SmartReading. Dunque, a telemetria senza campionamentu hè di leghje ogni "pagina" di u trafficu di a rete, vale à dì, analizendu metadata per ogni pacchettu. A telemetria mostrata hè u studiu selettivu di u trafficu in a speranza chì i campioni selezziunati cuntenenu ciò chì avete bisognu. Sicondu a velocità di u canali, a telemetria campionata serà mandata per analisi ogni 64th, 200th, 500th, 1000th, 2000th o ancu 10000th packet.
In u cuntestu di u monitoraghju di a sicurità di l'infurmazioni, questu significa chì a telemetria campionata hè bè adattata per a rilevazione di attacchi DDoS, scanning, è sparghje codice maliziusu, ma pò mancassi attacchi atomici o multi-pacchetti chì ùn sò micca stati inclusi in a mostra mandata per analisi. A telemetria senza campionu ùn hà micca tali svantaghji. Cù questu, a gamma di attacchi rilevati hè assai più larga. Eccu una breve lista di avvenimenti chì ponu esse rilevati cù l'arnesi di analisi di telemetria di rete.
Di sicuru, qualchì analizatore di Netflow open source ùn vi permetterà micca di fà questu, postu chì u so compitu principale hè di cullà a telemetria è di fà l'analisi di basa da un puntu di vista IT. Per identificà e minacce di sicurezza di l'infurmazioni basatu nantu à u flussu, hè necessariu equipà l'analizzatore cù diversi motori è algoritmi, chì identificà i prublemi di cibersecurità basatu nantu à i campi Netflow standard o persunalizati, arricchisce i dati standard cù dati esterni da diverse fonti di Threat Intelligence, etc.
Dunque, se avete una scelta, sceglite Netflow o IPFIX. Ma ancu s'è u vostru equipamentu funziona solu cù sFlow, cum'è i fabricatori domestici, allora ancu in questu casu pudete prufittà da ellu in un cuntestu di sicurità.
In l'estiu di 2019, aghju analizatu e capacità chì i fabricatori di hardware di rete russi anu è tutti, senza NSG, Polygon è Craftway, anu annunziatu supportu per sFlow (almenu Zelax, Natex, Eltex, QTech, Rusteleteh).
A prossima quistione chì vi affruntà hè induve implementà u supportu di flussu per scopi di sicurezza? In fatti, a quistione ùn hè micca pusata sanu currettamente. L'equipaggiu mudernu sustene quasi sempre i protokolli di flussu. Dunque, riformulassi a quistione in modu diversu - induve hè u più efficau per cullà a telemetria da un puntu di vista di sicurità? A risposta serà abbastanza ovvia - à u livellu d'accessu, induve vi vede u 100% di tuttu u trafficu, induve averete infurmazioni detallate nantu à l'ospiti (MAC, VLAN, ID d'interfaccia), induve pudete ancu monitorà u trafficu P2P trà l'ospiti, chì hè criticu per scanning deteczione è distribuzione di codice maliziusu. À u livellu core, pudete simpricimenti ùn vede micca un pocu di u trafficu, ma à u livellu perimetru, vi vede un quartu di tuttu u vostru trafficu di rete. Ma s'è per qualchì mutivu avete i dispositi stranieri in a vostra reta chì permettenu à l'attaccanti "entra è esce" senza svià u perimetru, allora analizà a telemetria da questu ùn vi darà nunda. Dunque, per una cobertura massima, hè cunsigliatu per attivà a cullezzione di telemetria à u livellu di accessu. À u listessu tempu, vale a pena nutà chì ancu s'ellu si parla di virtualizazione o di cuntenituri, u supportu di flussu hè ancu spessu truvatu in i switches virtuali muderni, chì vi permette di cuntrullà u trafficu ancu quì.
Ma postu chì aghju suscitatu u tema, aghju bisognu di risponde à a quistione: chì si l'equipaggiu, fisicu o virtuale, ùn sustene micca i protokolli di flussu? O hè a so inclusione pruibita (per esempiu, in i segmenti industriali per assicurà a affidabilità)? O l'accensione porta à una alta carica di CPU (questu succede in hardware più anticu)? Per risolve stu prublema, ci sò sensori virtuali specializati (sensori di flussu), chì sò essenzialmente splitters ordinali chì passanu u trafficu per elli stessi è trasmettenu in forma di flussu à u modulu di cullezzione. True, in questu casu avemu tutti i prublemi chì avemu parlatu sopra in relazione à i strumenti di cattura di pacchetti. Questu hè, avete bisognu di capisce micca solu i vantaghji di a tecnulugia di analisi di flussu, ma ancu e so limitazioni.
Un altru puntu chì hè impurtante di ricurdà quandu si parla di strumenti di analisi di flussu. Se in relazione à i mezi cunvinziunali di generà avvenimenti di sicurezza, usemu a metrica EPS (avvenimentu per seconda), allora questu indicatore ùn hè micca applicabile à l'analisi di telemetria; hè rimpiazzatu da FPS (flussu per seconda). Cum'è in u casu di l'EPS, ùn pò micca esse calculatu in anticipu, ma pudete stimà u numeru apprussimativu di filamenti chì un dispositivu particulari genera secondu u so compitu. Pudete truvà tabelle in Internet cù valori apprussimativi per i sfarenti tippi di dispusitivi di l'impresa è e cundizioni, chì vi permettenu di stimà chì licenze avete bisognu per strumenti di analisi è quale serà a so architettura? U fattu hè chì u sensor IDS hè limitatu da una certa larghezza di banda chì pò "tirà", è u cullettore di flussu hà e so limitazioni chì deve esse capitu. Dunque, in e grande rete geograficamente distribuite, sò generalmente parechji cullettori. Quandu aghju descrittu , Aghju digià datu u nùmeru di i nostri cullettori - ci sò 21. È questu hè per una reta spargugliata in cinque cuntinenti è numerate circa a mità di milione di dispusitivi attivi).
Utilizemu a nostra propria suluzione cum'è sistema di monitoraghju Netflow , chì hè specificamente focu annantu à risolve i prublemi di sicurezza. Havi assai mutori integrati per a deteczione di l'attività anomala, sospetta è chjaramente maliciosa, chì vi permette di detectà una larga gamma di diverse minacce - da a criptografia à a fuga d'informazioni, da a diffusione di codice maliziusu à u fraud. Cum'è a maiò parte di l'analizzatori di flussu, Stealthwatch hè custruitu secondu un schema di trè livelli (generatore - cullettore - analizzatore), ma hè cumplementatu cù una quantità di funzioni interessanti chì sò impurtanti in u cuntestu di u materiale in cunsiderà. Prima, si integra cù e soluzioni di cattura di pacchetti (cum'è Cisco Security Packet Analyzer), chì vi permette di registrà e sessioni di rete selezziunate per una investigazione è analisi approfondita dopu. Siconda, specificamente per espansione i travaglii di sicurezza, avemu sviluppatu un protokollu nvzFlow speciale, chì permette di "diffusione" l'attività di l'applicazioni nantu à i nodi finali (servitori, stazioni di travagliu, etc.) in telemetria è trasmettenu à u cullettore per più analisi. Se in a so versione uriginale Stealthwatch travaglia cù qualsiasi protokollu di flussu (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) à u livellu di a rete, u supportu nvzFlow permette a correlazione di dati ancu à u nivellu di node, cusì. aumentendu l'efficienza di u sistema sanu è vede più attacchi chè l'analizzatori di flussu di rete cunvinziunali.
Hè chjaru chì quandu si parla di sistemi di analisi Netflow da un puntu di vista di sicurezza, u mercatu ùn hè micca limitatu à una solu suluzione da Cisco. Pudete aduprà solu suluzioni cummirciali è gratuiti o shareware. Hè abbastanza stranu s'ellu cite i suluzioni di i cuncurrenti cum'è esempi nantu à u blog di Cisco, cusì diceraghju uni pochi di parolle nantu à cumu a telemetria di a rete pò esse analizata cù dui strumenti populari, simili in nome, ma ancu diffirenti - SiLK è ELK.
SiLK hè un inseme di strumenti (u Sistema per a Cunniscenza à Livellu di Internet) per l'analisi di u trafficu, sviluppatu da u CERT/CC americanu è chì sustene, in u cuntestu di l'articulu d'oghje, Netflow (5 è 9, e versioni più populari), IPFIX. è sFlow è aduprendu diverse utilità (rwfilter, rwcount, rwflowpack, etc.) per fà diverse operazioni nantu à a telemetria di a rete per detectà segni di azioni micca autorizate in questu. Ma ci sò parechji punti impurtanti da nutà. SiLK hè un strumentu di linea di cummanda chì esegue analisi in linea inserendu cumandamenti cum'è questu (deteczione di pacchetti ICMP più grande di 200 byte):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
micca assai còmode. Pudete utilizà a GUI iSiLK, ma ùn farà micca a vostra vita assai più faciule, solu solu solu a funzione di visualizazione è micca rimpiazzà l'analista. È questu hè u sicondu puntu. A cuntrariu di suluzioni cummirciali, chì anu digià una basa analitica solida, algoritmi di rilevazione di anomalie, flussu di travagliu currispundenti, etc., in u casu di SiLK, duverete fà tuttu questu sè stessu, chì richiederà cumpetenze ligeramente sfarente da voi da l'utilizazione digià pronta. à aduprà arnesi. Questu hè nè bè nè male - questu hè una funzione di quasi ogni strumentu gratuitu chì assume chì sapete ciò chì fà, è vi aiuterà solu cù questu (arnesi di cummerciale sò menu dipindenti di e cumpetenze di i so utilizatori, ancu s'ellu assumenu ancu. chì l'analista capiscenu almenu e basi di l'investigazioni di a rete è u monitoraghju). Ma vultemu à SiLK. U ciclu di travagliu di l'analista cun questu hè cusì:
- Formulazione di una ipotesi. Avemu da capisce ciò chì cercheremu in a telemetria di a rete, cunnosce l'attributi unichi per quale identificheremu certe anomalie o minacce.
- Custruì un mudellu. Dopu avè formulatu una ipotesi, u prugrammu cù u stessu Python, cunchiglia o altre arnesi micca incluse in SiLK.
- Testing. Avà vene u turnu di verificà a correttezza di a nostra ipotesi, chì hè cunfirmata o refutata cù l'utilità SiLK chì cumincianu cù "rw", "set", "bag".
- Analisi di dati reali. In l'operazione industriale, SiLK ci aiuta à identificà qualcosa è l'analista deve risponde à e dumande "Avemu trovu ciò chì avemu aspittatu?", "Questu currisponde à a nostra ipotesi?", "Cumu riduce u numeru di falsi pusitivi?" per migliurà u livellu di ricunniscenza ? » eccetera.
- Migliuramentu. In u stadiu finali, migliurà ciò chì hè statu fattu prima - creamu mudelli, migliurà è ottimisimu u codice, riformulate è clarificà l'ipotesi, etc.
Stu ciclu serà ancu applicabile à Cisco Stealthwatch, solu l'ultimu automatizeghja questi cinque passi à u massimu, riducendu u numeru di errori di l'analista è aumentendu l'efficienza di a rilevazione di incidenti. Per esempiu, in SiLK pudete arricchisce statistiche di a rete cù dati esterni nantu à IP maliziusi cù script scritti a manu, è in Cisco Stealthwatch hè una funzione integrata chì mostra immediatamente una alarma se u trafficu di a rete cuntene interazzione cù l'indirizzi IP da a lista negra.
Se vai più altu in a piramide "pagata" per u software di analisi di flussu, dopu à u SiLK assolutamente liberu, ci sarà un ELK shareware, custituitu di trè cumpunenti chjave - Elasticsearch (indexazione, ricerca è analisi di dati), Logstash (input / output di dati). ) è Kibana (visualizazione). A cuntrariu di SiLK, induve duvete scrive tuttu, ELK hà digià parechje librerie / moduli pronti (alcuni pagati, altri micca) chì automatizanu l'analisi di a telemetria di a rete. Per esempiu, u filtru GeoIP in Logstash permette di associà l'indirizzi IP monitorati cù a so situazione geografica (Stealthwatch hà sta funzione integrata).
ELK hà ancu una cumunità abbastanza grande chì compie i cumpunenti mancanti per sta suluzione di monitoraghju. Per esempiu, per travaglià cù Netflow, IPFIX è sFlow pudete aduprà u modulu , Se ùn site micca cuntentu cù u Modulu Logstash Netflow, chì solu sustene Netflow.
Mentre dà più efficienza in a cullizzioni di flussu è a ricerca in questu, ELK manca attualmente una ricca analisi integrata per a rilevazione di anomalie è minacce in telemetria di rete. Vale à dì, dopu à u ciculu di vita descrittu sopra, duverete descriverà indipindentamente mudelli di violazione è dopu aduprà in u sistema di cummattimentu (ùn ci hè micca mudelli integrati).
Ci hè, sicuru, estensioni più sufisticati per ELK, chì cuntenenu digià qualchi mudelli per a rilevazione di anomalie in a telemetria di a rete, ma tali estensioni costanu soldi è quì a quistione hè se u ghjocu vale a pena a candela - scrivite un mudellu simili, cumprà u so propiu. implementazione per u vostru strumentu di surviglianza, o cumprà una suluzione pronta di a classa di Analisi di Traffic Network.
In generale, ùn vogliu micca entra in u dibattitu chì hè megliu per gastà soldi è cumprà una suluzione pronta per u monitoraghju di anomalie è minacce in a telemetria di a rete (per esempiu, Cisco Stealthwatch) o scuprite sè stessu è persunalizà u listessu. SiLK, ELK o nfdump o OSU Flow Tools per ogni nova minaccia (parlu di l'ultimi dui di elli l'ultima volta)? Ognunu sceglie per sè stessu è ognunu hà i so motivi per sceglie una di e duie opzioni. Vuliu solu dimustrà chì a telemetria di a rete hè un strumentu assai impurtante per assicurà a sicurezza di a rete di a vostra infrastruttura interna è ùn deve micca trascuratu, per ùn unisce à a lista di cumpagnie chì u nome hè citatu in i media cù l'epiteti " hacked", "non-conforming with information security requirements" ", "micca pensendu à a sicurità di i so dati è dati di i clienti".
Per riassume, vogliu elencu i cunsiglii chjave chì duvete seguità quandu custruite u monitoraghju di a sicurità di l'infurmazioni di a vostra infrastruttura interna:
- Ùn limità micca solu à u perimetru! Aduprate (è sceglite) l'infrastruttura di rete micca solu per spustà u trafficu da u puntu A à u puntu B, ma ancu per affruntà i prublemi di cibersigurtà.
- Studiate i meccanismi di monitoraghju di a sicurità di l'infurmazioni esistenti in u vostru equipamentu di rete è aduprate.
- Per u monitoraghju internu, dà preferenza à l'analisi di telemetria - vi permette di detectà finu à u 80-90% di tutti l'incidenti di sicurezza di l'infurmazioni di a rete, mentre fate ciò chì hè impussibile quandu catturà pacchetti di rete è risparmià spaziu per almacenà tutti l'avvenimenti di sicurezza di l'infurmazioni.
- Per monitorà i flussi, utilizate Netflow v9 o IPFIX - furnisce più infurmazioni in un cuntestu di sicurità è permettenu di monitorà micca solu IPv4, ma ancu IPv6, MPLS, etc.
- Aduprate un protokollu di flussu senza campionamentu - furnisce più infurmazioni per a deteczione di minacce. Per esempiu, Netflow o IPFIX.
- Verificate a carica nantu à u vostru equipamentu di rete - ùn pò micca esse capace di trattà ancu u protocolu di flussu. Allora cunzidira l'usu di sensori virtuali o Netflow Generation Appliance.
- Implementà u cuntrollu prima di tuttu à u livellu di accessu - questu vi darà l'uppurtunità di vede 100% di tuttu u trafficu.
- Se ùn avete micca scelta è utilizate l'equipaggiu di rete russa, sceglite quellu chì sustene i protokolli di flussu o chì hà porti SPAN / RSPAN.
- Unisce sistemi di rilevazione / prevenzione di intrusioni / attacchi à i bordi è sistemi di analisi di flussu in a reta interna (cumprese in i nuvuli).
In quantu à l'ultima punta, vogliu dà un'illustrazione chì aghju digià datu prima. Avete vistu chì, se prima u serviziu di sicurità di l'infurmazioni Cisco hà custruitu guasi cumplettamente u so sistema di surviglianza di a sicurità di l'infurmazioni nantu à a basa di i sistemi di rilevazione di intrusioni è i metudi di firma, avà sò solu 20% di incidenti. Un altru 20% cade nantu à i sistemi di analisi di flussu, chì suggerisce chì sti suluzioni ùn sò micca un capriccio, ma un veru strumentu in l'attività di servizii di sicurità di l'infurmazioni di una impresa muderna. Inoltre, avete u più impurtante per a so implementazione - infrastruttura di rete, investimenti in quale pò esse più prutetti da l'assignazione di funzioni di monitoraghju di sicurità di l'infurmazioni à a reta.
Ùn aghju micca specificamente toccu u tema di risponde à anomalie o minacce identificate in i flussi di rete, ma pensu chì hè digià chjaru chì u monitoraghju ùn deve micca finisce solu cù a deteczione di una minaccia. Hè da esse seguita da una risposta è preferibile in modu automaticu o automatizatu. Ma questu hè un tema per un articulu separatu.
Additional information:
PS. S'ellu hè più faciule per voi per sente tuttu ciò chì hè statu scrittu sopra, pudete guardà a presentazione di l'ora chì formava a basa di sta nota.
Source: www.habr.com