Când vine vorba de monitorizarea securității unei rețele interne corporative sau departamentale, mulți o asociază cu controlul scurgerilor de informații și cu implementarea soluțiilor DLP. Și dacă încercați să clarificați întrebarea și să întrebați cum detectați atacurile asupra rețelei interne, atunci răspunsul va fi, de regulă, o mențiune despre sistemele de detectare a intruziunilor (IDS). Și ceea ce era singura opțiune acum 10-20 de ani devine un anacronism astăzi. Există o opțiune mai eficientă și, în unele locuri, singura posibilă pentru monitorizarea unei rețele interne - folosind protocoale de flux, care au fost concepute inițial pentru a căuta probleme de rețea (depanare), dar în timp s-au transformat într-un instrument de securitate foarte interesant. Vom vorbi despre ce protocoale de flux există și care sunt mai bune la detectarea atacurilor de rețea, unde este cel mai bine să implementați monitorizarea fluxului, ce să căutați atunci când implementați o astfel de schemă și chiar cum să „ridicați” toate acestea pe echipamentele casnice. în sfera de aplicare a acestui articol.
Nu mă voi opri la întrebarea „De ce este necesară monitorizarea securității infrastructurii interne?” Răspunsul pare a fi clar. Dar dacă, totuși, ai vrea să te asiguri încă o dată că astăzi nu poți trăi fără ea, un scurt videoclip despre cum puteți pătrunde într-o rețea corporativă protejată de un firewall în 17 moduri. Prin urmare, vom presupune că înțelegem că monitorizarea internă este un lucru necesar și nu mai rămâne decât să înțelegem cum poate fi organizată.
Aș evidenția trei surse cheie de date pentru monitorizarea infrastructurii la nivel de rețea:
- trafic „brut” pe care îl captăm și îl trimitem spre analiză anumitor sisteme de analiză,
- evenimente de la dispozitivele de rețea prin care trece traficul,
- informații de trafic primite prin intermediul unuia dintre protocoalele de flux.
Captarea traficului brut este cea mai populară opțiune în rândul specialiștilor în securitate, deoarece a apărut istoric și a fost chiar prima. Sistemele convenționale de detectare a intruziunilor în rețea (primul sistem comercial de detectare a intruziunilor a fost NetRanger de la Wheel Group, achiziționat în 1998 de Cisco) erau tocmai angajați în capturarea pachetelor (și a sesiunilor ulterioare) în care erau căutate anumite semnături („reguli decisive” în terminologia FSTEC), semnalizarea atacurilor. Desigur, puteți analiza traficul brut nu numai folosind IDS, ci și folosind alte instrumente (de exemplu, Wireshark, tcpdum sau funcționalitatea NBAR2 din Cisco IOS), dar de obicei le lipsește baza de cunoștințe care distinge un instrument de securitate a informațiilor de unul obișnuit. instrument IT.
Deci, sistemele de detectare a atacurilor. Cea mai veche și populară metodă de detectare a atacurilor de rețea, care face o treabă bună la perimetru (indiferent de ce - corporație, centru de date, segment etc.), dar eșuează în rețelele moderne comutate și definite de software. În cazul unei rețele construite pe baza de switch-uri convenționale, infrastructura senzorilor de detectare a atacurilor devine prea mare - va trebui să instalați câte un senzor pe fiecare conexiune la nodul pe care doriți să monitorizați atacurile. Orice producător, desigur, va fi bucuros să vă vândă sute și mii de senzori, dar cred că bugetul dumneavoastră nu poate suporta astfel de cheltuieli. Pot spune că nici la Cisco (și suntem dezvoltatorii NGIPS) nu am putut face asta, deși s-ar părea că problema prețului este în fața noastră. Nu ar trebui să suport - este propria noastră decizie. În plus, apare întrebarea, cum să conectați senzorul în această versiune? În gol? Ce se întâmplă dacă senzorul în sine eșuează? Necesită un modul de bypass în senzor? Folosiți splittere (atingeți)? Toate acestea fac soluția mai costisitoare și o fac inaccesabilă pentru o companie de orice dimensiune.
Puteți încerca să „atârniți” senzorul pe un port SPAN/RSPAN/ERSPAN și să direcționați traficul de la porturile de comutare necesare către acesta. Această opțiune înlătură parțial problema descrisă în paragraful anterior, dar pune una alta - portul SPAN nu poate accepta absolut tot traficul care îi va fi trimis - nu va avea suficientă lățime de bandă. Va trebui să sacrifici ceva. Fie lăsați unele dintre noduri fără monitorizare (atunci trebuie să le prioritizați mai întâi), fie trimiteți nu tot traficul de la nod, ci doar un anumit tip. În orice caz, putem rata unele atacuri. În plus, portul SPAN poate fi folosit pentru alte nevoi. Ca urmare, va trebui să revizuim topologia rețelei existente și, eventual, să facem ajustări la aceasta pentru a acoperi rețeaua la maximum cu numărul de senzori pe care îl aveți (și să coordonăm acest lucru cu IT).
Ce se întâmplă dacă rețeaua dvs. folosește rute asimetrice? Ce se întâmplă dacă ați implementat sau plănuiți să implementați SDN? Ce se întâmplă dacă trebuie să monitorizați mașinile virtualizate sau containerele al căror trafic nu ajunge deloc la comutatorul fizic? Acestea sunt întrebări la care vânzătorii tradiționali de IDS nu le plac pentru că nu știu cum să le răspundă. Poate că vă vor convinge că toate aceste tehnologii la modă sunt hype și nu aveți nevoie de el. Poate vor vorbi despre necesitatea de a începe cu mici. Sau poate ei vor spune că trebuie să puneți un treierator puternic în centrul rețelei și să direcționați tot traficul către ea folosind balansoare. Indiferent de opțiunea care vi se oferă, trebuie să înțelegeți clar cum vi se potrivește. Și numai după aceea luați o decizie cu privire la alegerea unei abordări pentru monitorizarea securității informaționale a infrastructurii de rețea. Revenind la captarea pachetelor, vreau să spun că această metodă continuă să fie foarte populară și importantă, dar scopul ei principal este controlul la frontieră; granițele dintre organizația dvs. și Internet, granițele dintre centrul de date și restul rețelei, granițele dintre sistemul de control al procesului și segmentul corporativ. În aceste locuri, IDS/IPS clasice au încă dreptul să existe și să facă față bine sarcinilor lor.
Să trecem la a doua variantă. Analiza evenimentelor care provin de la dispozitivele din rețea poate fi folosită și în scopuri de detectare a atacurilor, dar nu ca mecanism principal, deoarece permite detectarea doar a unei clase mici de intruziuni. În plus, este inerent unei anumite reactivitati - atacul trebuie să aibă loc mai întâi, apoi trebuie înregistrat de un dispozitiv de rețea, care într-un fel sau altul va semnala o problemă cu securitatea informațiilor. Există mai multe astfel de moduri. Acesta poate fi syslog, RMON sau SNMP. Ultimele două protocoale pentru monitorizarea rețelei în contextul securității informațiilor sunt utilizate numai dacă trebuie să detectăm un atac DoS asupra echipamentului de rețea în sine, deoarece folosind RMON și SNMP este posibil, de exemplu, să monitorizăm încărcarea pe centrala dispozitivului. procesor sau interfețele acestuia. Aceasta este una dintre cele mai „ieftine” (toată lumea are syslog sau SNMP), dar și cea mai ineficientă dintre toate metodele de monitorizare a securității informațiilor a infrastructurii interne - multe atacuri sunt pur și simplu ascunse de ea. Desigur, nu trebuie neglijate, iar aceeași analiză syslog vă ajută să identificați în timp util modificările în configurația dispozitivului în sine, compromisul acestuia, dar nu este foarte potrivit pentru detectarea atacurilor asupra întregii rețele.
A treia opțiune este analizarea informațiilor despre traficul care trece printr-un dispozitiv care acceptă unul dintre mai multe protocoale de flux. În acest caz, indiferent de protocol, infrastructura de threading constă în mod necesar din trei componente:
- Generarea sau exportul fluxului. Acest rol este de obicei atribuit unui router, comutator sau altui dispozitiv de rețea, care, prin trecerea traficului de rețea prin el însuși, vă permite să extrageți parametri cheie din acesta, care sunt apoi transmise la modulul de colectare. De exemplu, Cisco acceptă protocolul Netflow nu numai pe routere și switch-uri, inclusiv pe cele virtuale și industriale, ci și pe controlere wireless, firewall-uri și chiar servere.
- Fluxul de colectare. Având în vedere că o rețea modernă are de obicei mai multe dispozitive de rețea, se pune problema colectării și consolidării fluxurilor, care se rezolvă cu ajutorul așa-numiților colectori, care procesează fluxurile primite și apoi le transmit spre analiză.
- Analiza fluxului Analizatorul preia sarcina intelectuală principală și, aplicând diferiți algoritmi fluxurilor, trage anumite concluzii. De exemplu, ca parte a unei funcții IT, un astfel de analizor poate identifica blocajele de rețea sau poate analiza profilul de încărcare a traficului pentru optimizarea ulterioară a rețelei. Iar pentru securitatea informațiilor, un astfel de analizor poate detecta scurgerile de date, răspândirea codului rău intenționat sau atacurile DoS.
Nu credeți că această arhitectură cu trei niveluri este prea complicată - toate celelalte opțiuni (cu excepția, poate, sistemele de monitorizare a rețelei care funcționează cu SNMP și RMON) funcționează, de asemenea, conform acesteia. Avem un generator de date pentru analiză, care poate fi un dispozitiv de rețea sau un senzor de sine stătător. Avem un sistem de colectare a alarmelor și un sistem de management pentru întreaga infrastructură de monitorizare. Ultimele două componente pot fi combinate într-un singur nod, dar în rețelele mai mult sau mai puțin mari ele sunt de obicei răspândite pe cel puțin două dispozitive pentru a asigura scalabilitatea și fiabilitatea.
Spre deosebire de analiza pachetelor, care se bazează pe studierea antetului și a datelor corporale ale fiecărui pachet și a sesiunilor din care constă, analiza fluxului se bazează pe colectarea metadatelor despre traficul de rețea. Când, cât, de unde și unde, cum... acestea sunt întrebările la care se răspunde analiza telemetriei rețelei folosind diverse protocoale de flux. Inițial, acestea au fost folosite pentru a analiza statistici și a găsi probleme IT în rețea, dar apoi, pe măsură ce mecanismele analitice s-au dezvoltat, a devenit posibilă aplicarea lor la aceeași telemetrie din motive de securitate. Merită remarcat din nou că analiza fluxului nu înlocuiește sau înlocuiește captura de pachete. Fiecare dintre aceste metode are propriul domeniu de aplicare. Dar, în contextul acestui articol, analiza fluxului este cea mai potrivită pentru monitorizarea infrastructurii interne. Aveți dispozitive de rețea (fie că funcționează într-o paradigmă definită de software sau conform regulilor statice) pe care un atac nu le poate ocoli. Poate ocoli un senzor IDS clasic, dar un dispozitiv de rețea care acceptă protocolul de flux nu poate. Acesta este avantajul acestei metode.
Pe de altă parte, dacă aveți nevoie de dovezi pentru forțele de ordine sau pentru propria echipă de investigare a incidentelor, nu puteți face fără captarea pachetelor - telemetria de rețea nu este o copie a traficului care poate fi folosită pentru a colecta dovezi; este necesar pentru detectarea rapidă și luarea deciziilor în domeniul securității informațiilor. Pe de altă parte, folosind analiza de telemetrie, puteți „scrie” nu tot traficul de rețea (dacă este ceva, Cisco se ocupă de centrele de date :-), ci doar de ceea ce este implicat în atac. Instrumentele de analiză de telemetrie în acest sens vor completa bine mecanismele tradiționale de captare a pachetelor, oferind comenzi pentru capturarea și stocarea selectivă. În caz contrar, va trebui să ai o infrastructură de stocare colosală.
Să ne imaginăm o rețea care funcționează la o viteză de 250 Mbit/sec. Dacă doriți să stocați tot acest volum, atunci veți avea nevoie de 31 MB de spațiu de stocare pentru o secundă de transmisie a traficului, 1,8 GB pentru un minut, 108 GB pentru o oră și 2,6 TB pentru o zi. Pentru a stoca date zilnice dintr-o rețea cu o lățime de bandă de 10 Gbit/s, veți avea nevoie de 108 TB de stocare. Dar unii autorități de reglementare solicită stocarea datelor de securitate ani de zile... Înregistrarea la cerere, pe care analiza fluxului vă ajută să o implementați, ajută la reducerea acestor valori cu ordine de mărime. Apropo, dacă vorbim despre raportul dintre volumul de date înregistrate de telemetrie de rețea și captarea completă a datelor, atunci este de aproximativ 1 la 500. Pentru aceleași valori date mai sus, stocarea unei transcriere completă a întregului trafic zilnic va fi de 5, respectiv 216 GB (poți chiar să-l înregistrezi pe o unitate flash obișnuită).
Dacă pentru instrumentele de analiză a datelor brute din rețea, metoda de captare a acestora este aproape aceeași de la furnizor la furnizor, atunci în cazul analizei fluxului situația este diferită. Există mai multe opțiuni pentru protocoalele de flux, diferențele în care trebuie să cunoașteți în contextul securității. Cel mai popular este protocolul Netflow dezvoltat de Cisco. Există mai multe versiuni ale acestui protocol, care diferă în ceea ce privește capacitățile și cantitatea de informații despre trafic înregistrate. Versiunea actuală este a noua (Netflow v9), pe baza căreia a fost dezvoltat standardul industrial Netflow v10, cunoscut și sub numele de IPFIX. Astăzi, majoritatea furnizorilor de rețele acceptă Netflow sau IPFIX în echipamentele lor. Dar există diverse alte opțiuni pentru protocoalele de flux - sFlow, jFlow, cFlow, rFlow, NetStream etc., dintre care sFlow este cel mai popular. Acest tip este cel mai adesea susținut de producătorii autohtoni de echipamente de rețea datorită ușurinței sale de implementare. Care sunt diferențele cheie dintre Netflow, care a devenit un standard de facto, și sFlow? Aș evidenția câteva dintre cele cheie. În primul rând, Netflow are câmpuri personalizabile de utilizator, spre deosebire de câmpurile fixe din sFlow. Și în al doilea rând, și acesta este cel mai important lucru în cazul nostru, sFlow colectează așa-numita telemetrie eșantionată; spre deosebire de cel neeșantionat pentru Netflow și IPFIX. Care este diferența dintre ele?
Imaginează-ți că te decizi să citești cartea „” ai colegilor mei - Gary McIntyre, Joseph Munitz și Nadem Alfardan (puteți descărca o parte din carte de pe link). Aveți trei opțiuni pentru a vă atinge obiectivul - citiți întreaga carte, răsfoiți-o, opriți-vă la fiecare a 10-a sau a 20-a pagină sau încercați să găsiți o repovestire a conceptelor cheie pe un blog sau un serviciu precum SmartReading. Deci, telemetria neeșantionată citește fiecare „pagină” a traficului de rețea, adică analizează metadatele pentru fiecare pachet. Telemetria eșantionată este studiul selectiv al traficului în speranța că mostrele selectate vor conține ceea ce aveți nevoie. În funcție de viteza canalului, telemetria eșantionată va fi trimisă pentru analiză la fiecare pachet 64, 200, 500, 1000, 2000 sau chiar al 10000.
În contextul monitorizării securității informațiilor, aceasta înseamnă că telemetria eșantionată este potrivită pentru detectarea atacurilor DDoS, scanarea și răspândirea codului rău intenționat, dar poate rata atacuri atomice sau multi-pachete care nu au fost incluse în eșantionul trimis pentru analiză. Telemetria neeșantionată nu are astfel de dezavantaje. Cu aceasta, gama de atacuri detectate este mult mai largă. Iată o listă scurtă de evenimente care pot fi detectate folosind instrumente de analiză a telemetriei rețelei.
Desigur, un analizor Netflow open source nu vă va permite să faceți acest lucru, deoarece sarcina sa principală este de a colecta telemetria și de a efectua analize de bază din punct de vedere IT. Pentru a identifica amenințările la securitatea informațiilor pe baza fluxului, este necesară dotarea analizorului cu diverse motoare și algoritmi, care vor identifica problemele de securitate cibernetică pe baza câmpurilor Netflow standard sau personalizate, îmbogăți datele standard cu date externe din diverse surse Threat Intelligence etc.
Prin urmare, dacă aveți de ales, alegeți Netflow sau IPFIX. Dar chiar dacă echipamentul tău funcționează doar cu sFlow, ca și producătorii autohtoni, atunci și în acest caz poți beneficia de el în context de securitate.
În vara lui 2019, am analizat capacitățile pe care producătorii ruși de hardware de rețea le au și toți aceștia, cu excepția NSG, Polygon și Craftway, au anunțat suport pentru sFlow (cel puțin Zelax, Natex, Eltex, QTech, Rusteleteh).
Următoarea întrebare cu care vă veți confrunta este unde să implementați suportul pentru flux în scopuri de securitate? De fapt, întrebarea nu este pusă în întregime corect. Echipamentele moderne suportă aproape întotdeauna protocoale de flux. Prin urmare, aș reformula altfel întrebarea - unde este cel mai eficient să colectezi telemetria din punct de vedere al securității? Răspunsul va fi destul de evident - la nivelul de acces, unde vei vedea 100% din tot traficul, unde vei avea informații detaliate despre gazde (MAC, VLAN, ID interfață), unde poți chiar monitoriza traficul P2P între gazde, care este esențial pentru detectarea scanării și distribuirea codului rău intenționat. La nivel de bază, este posibil să nu vedeți o parte din trafic, dar la nivel de perimetru, veți vedea un sfert din tot traficul din rețea. Dar dacă dintr-un motiv oarecare aveți dispozitive străine în rețea care permit atacatorilor „să intre și să iasă” fără a ocoli perimetrul, atunci analizarea telemetriei din acesta nu vă va oferi nimic. Prin urmare, pentru o acoperire maximă, se recomandă activarea colectării telemetriei la nivel de acces. În același timp, este de remarcat faptul că, chiar dacă vorbim de virtualizare sau containere, suportul pentru flux se găsește adesea și în switch-urile virtuale moderne, ceea ce vă permite să controlați traficul și acolo.
Dar, din moment ce am ridicat subiectul, trebuie să răspund la întrebarea: ce se întâmplă dacă echipamentul, fizic sau virtual, nu acceptă protocoale de flux? Sau este interzisă includerea lui (de exemplu, în segmentele industriale pentru a asigura fiabilitatea)? Sau pornirea acestuia duce la o încărcare mare a procesorului (acest lucru se întâmplă pe hardware mai vechi)? Pentru a rezolva această problemă, există senzori virtuali specializați (senzori de flux), care sunt, în esență, distribuitoare obișnuite care trec traficul prin ei înșiși și îl difuzează sub formă de flux către modulul de colectare. Adevărat, în acest caz avem toate problemele despre care am vorbit mai sus în legătură cu instrumentele de captare a pachetelor. Adică, trebuie să înțelegeți nu numai avantajele tehnologiei de analiză a fluxului, ci și limitările acesteia.
Un alt punct care este important de reținut atunci când vorbim despre instrumentele de analiză a fluxului. Dacă în raport cu mijloacele convenționale de generare a evenimentelor de securitate folosim metrica EPS (eveniment pe secundă), atunci acest indicator nu este aplicabil analizei de telemetrie; este înlocuit cu FPS (flux pe secundă). Ca și în cazul EPS, acesta nu poate fi calculat în avans, dar puteți estima numărul aproximativ de fire pe care le generează un anumit dispozitiv în funcție de sarcina acestuia. Puteți găsi pe Internet tabele cu valori aproximative pentru diferite tipuri de dispozitive și condiții de întreprindere, care vă vor permite să estimați ce licențe aveți nevoie pentru instrumentele de analiză și care va fi arhitectura acestora? Cert este că senzorul IDS este limitat de o anumită lățime de bandă pe care o poate „trage”, iar colectorul de flux are propriile limitări care trebuie înțelese. Prin urmare, în rețelele mari, distribuite geografic, există de obicei mai mulți colectori. Când am descris , am dat deja numărul colecționarilor noștri - sunt 21. Și aceasta este pentru o rețea împrăștiată pe cinci continente și numărând aproximativ jumătate de milion de dispozitive active).
Utilizăm propria noastră soluție ca sistem de monitorizare Netflow , care se concentrează în mod special pe rezolvarea problemelor de securitate. Are multe motoare încorporate pentru detectarea activităților anormale, suspecte și clar rău intenționate, ceea ce vă permite să detectați o gamă largă de amenințări diferite - de la criptomining la scurgeri de informații, de la răspândirea codului rău intenționat la fraudă. La fel ca majoritatea analizoarelor de flux, Stealthwatch este construit după o schemă pe trei niveluri (generator - colector - analizor), dar este completat cu o serie de caracteristici interesante care sunt importante în contextul materialului luat în considerare. În primul rând, se integrează cu soluții de captare a pachetelor (cum ar fi Cisco Security Packet Analyzer), care vă permite să înregistrați sesiunile de rețea selectate pentru investigații și analize aprofundate ulterioare. În al doilea rând, special pentru a extinde sarcinile de securitate, am dezvoltat un protocol special nvzFlow, care vă permite să „difuzați” activitatea aplicațiilor pe nodurile finale (servere, stații de lucru etc.) în telemetrie și să o transmiteți colectorului pentru analize ulterioare. Dacă în versiunea sa originală Stealthwatch funcționează cu orice protocol de flux (sFlow, rFlow, Netflow, IPFIX, cFlow, jFlow, NetStream) la nivel de rețea, atunci suportul nvzFlow permite corelarea datelor și la nivel de nod, prin urmare. creșterea eficienței întregului sistem și observarea mai multor atacuri decât analizoarele convenționale de flux de rețea.
Este clar că atunci când vorbim despre sisteme de analiză Netflow din punct de vedere al securității, piața nu se limitează la o singură soluție de la Cisco. Puteți utiliza atât soluții comerciale, cât și gratuite sau shareware. Este destul de ciudat dacă citez soluțiile concurenților ca exemple pe blogul Cisco, așa că voi spune câteva cuvinte despre modul în care telemetria de rețea poate fi analizată folosind două instrumente populare, similare ca nume, dar încă diferite - SiLK și ELK.
SiLK este un set de instrumente (The System for Internet-Level Knowledge) pentru analiza traficului, dezvoltat de CERT/CC american și care suportă, în contextul articolului de astăzi, Netflow (a 5-a și a 9-a, cele mai populare versiuni), IPFIX. și sFlow și utilizarea diverselor utilități (rwfilter, rwcount, rwflowpack etc.) pentru a efectua diverse operațiuni pe telemetria rețelei pentru a detecta semne de acțiuni neautorizate în aceasta. Dar există câteva puncte importante de reținut. SiLK este un instrument de linie de comandă care efectuează analize on-line introducând comenzi ca aceasta (detecția pachetelor ICMP mai mari de 200 de octeți):
rwfilter --flowtypes=all/all --proto=1 --bytes-per-packet=200- --pass=stdout | rwrwcut --fields=sIP,dIP,iType,iCode --num-recs=15
nu foarte confortabil. Puteți folosi interfața grafică iSiLK, dar nu vă va ușura mult viața, doar rezolvând funcția de vizualizare și nu înlocuind analistul. Și acesta este al doilea punct. Spre deosebire de soluțiile comerciale, care au deja o bază analitică solidă, algoritmi de detectare a anomaliilor, fluxul de lucru corespunzător etc., în cazul SiLK va trebui să faci toate acestea singur, ceea ce va necesita competențe ușor diferite de la tine față de utilizarea deja gata- instrumente de utilizare. Acest lucru nu este nici bun, nici rău - aceasta este o caracteristică a aproape orice instrument gratuit care presupune că știți ce să faceți și vă va ajuta doar cu acest lucru (instrumentele comerciale sunt mai puțin dependente de competențele utilizatorilor săi, deși ei presupun și ca analiștii să înțeleagă cel puțin elementele de bază ale investigațiilor și monitorizării rețelei). Dar să revenim la Mătase. Ciclul de lucru al analistului cu acesta arată astfel:
- Formularea unei ipoteze. Trebuie să înțelegem ce vom căuta în interiorul telemetriei rețelei, să cunoaștem atributele unice prin care vom identifica anumite anomalii sau amenințări.
- Construirea unui model. După ce am formulat o ipoteză, o programăm folosind același Python, shell sau alte instrumente care nu sunt incluse în SiLK.
- Testare. Acum vine rândul să verificăm corectitudinea ipotezei noastre, care este confirmată sau infirmată folosind utilitatile SiLK care încep cu „rw”, „set”, „bag”.
- Analiza datelor reale. În operațiunea industrială, SiLK ne ajută să identificăm ceva, iar analistul trebuie să răspundă la întrebările „Am găsit ceea ce ne așteptam?”, „Cospunde asta cu ipoteza noastră?”, „Cum să reducem numărul de fals pozitive?”, „Cum pentru a îmbunătăți nivelul de recunoaștere? » și așa mai departe.
- Îmbunătăţire. În etapa finală, îmbunătățim ceea ce s-a făcut mai devreme - creăm șabloane, îmbunătățim și optimizăm codul, reformulăm și clarificăm ipoteza etc.
Acest ciclu va fi aplicabil și pentru Cisco Stealthwatch, doar ultimul automatizează acești cinci pași la maximum, reducând numărul de erori ale analistului și crescând eficiența detectării incidentelor. De exemplu, în SiLK puteți îmbogăți statisticile rețelei cu date externe despre IP-uri rău intenționate folosind scripturi scrise de mână, iar în Cisco Stealthwatch este o funcție încorporată care afișează imediat o alarmă dacă traficul de rețea conține interacțiuni cu adrese IP din lista neagră.
Dacă mergeți mai sus în piramida „plătită” pentru software-ul de analiză a fluxului, atunci după SiLK absolut gratuit va exista un shareware ELK, format din trei componente cheie - Elasticsearch (indexare, căutare și analiză a datelor), Logstash (intrare/ieșire de date). ) și Kibana (vizualizare). Spre deosebire de SiLK, unde trebuie să scrii totul singur, ELK are deja multe biblioteci/module gata făcute (unele plătite, altele nu) care automatizează analiza telemetriei rețelei. De exemplu, filtrul GeoIP din Logstash vă permite să asociați adrese IP monitorizate cu locația lor geografică (Stealthwatch are această caracteristică încorporată).
ELK are, de asemenea, o comunitate destul de mare care completează componentele lipsă pentru această soluție de monitorizare. De exemplu, pentru a lucra cu Netflow, IPFIX și sFlow puteți utiliza modulul , dacă nu sunteți mulțumit de Modulul Logstash Netflow, care acceptă doar Netflow.
În timp ce oferă mai multă eficiență în colectarea fluxului și căutarea în acesta, ELK nu are în prezent o analiză bogată încorporată pentru detectarea anomaliilor și amenințărilor în telemetria rețelei. Adică, urmând ciclul de viață descris mai sus, va trebui să descrii în mod independent modelele de încălcare și apoi să le folosești în sistemul de luptă (nu există modele încorporate acolo).
Există, desigur, extensii mai sofisticate pentru ELK, care conțin deja câteva modele pentru detectarea anomaliilor în telemetria rețelei, dar astfel de extensii costă bani și întrebarea este dacă jocul merită lumânarea - scrieți singur un model similar, cumpărați implementarea lui. pentru instrumentul dvs. de monitorizare sau cumpărați o soluție gata făcută din clasa Analiza traficului în rețea.
În general, nu vreau să intru în dezbaterea că este mai bine să cheltuiți bani și să cumpărați o soluție gata făcută pentru monitorizarea anomaliilor și amenințărilor în telemetria rețelei (de exemplu, Cisco Stealthwatch) sau să vă dați seama și să personalizați la fel. SiLK, ELK sau nfdump sau OSU Flow Tools pentru fiecare amenințare nouă (vorbesc despre ultimele două dintre ele ultima data)? Fiecare alege pentru sine și fiecare are propriile motive pentru a alege oricare dintre cele două opțiuni. Am vrut doar să arăt că telemetria de rețea este un instrument foarte important în asigurarea securității rețelei a infrastructurii tale interne și nu trebuie să o neglijezi, pentru a nu intra pe lista companiilor al căror nume este menționat în mass-media alături de epitetele „ piratat”, „neconforme cu cerințele de securitate a informațiilor”, „nu se gândesc la securitatea datelor lor și a datelor clienților”.
Pentru a rezuma, aș dori să enumerez sfaturile cheie pe care ar trebui să le urmați atunci când construiți monitorizarea securității informațiilor a infrastructurii dvs. interne:
- Nu te limita doar la perimetru! Folosiți (și alegeți) infrastructura de rețea nu numai pentru a muta traficul din punctul A în punctul B, ci și pentru a rezolva problemele de securitate cibernetică.
- Studiați mecanismele existente de monitorizare a securității informațiilor în echipamentele dvs. de rețea și utilizați-le.
- Pentru monitorizarea internă, acordați preferință analizei de telemetrie - vă permite să detectați până la 80-90% din toate incidentele de securitate a informațiilor din rețea, în timp ce faceți ceea ce este imposibil atunci când capturați pachete de rețea și economisiți spațiu pentru stocarea tuturor evenimentelor de securitate a informațiilor.
- Pentru a monitoriza fluxurile, utilizați Netflow v9 sau IPFIX - acestea oferă mai multe informații într-un context de securitate și vă permit să monitorizați nu numai IPv4, ci și IPv6, MPLS etc.
- Utilizați un protocol de flux neeșantionat - oferă mai multe informații pentru detectarea amenințărilor. De exemplu, Netflow sau IPFIX.
- Verificați încărcarea echipamentului dvs. de rețea - este posibil să nu poată gestiona și protocolul de flux. Apoi luați în considerare utilizarea senzorilor virtuali sau a dispozitivului Netflow Generation.
- Implementați controlul în primul rând la nivelul de acces - acest lucru vă va oferi posibilitatea de a vedea 100% din tot traficul.
- Dacă nu aveți de ales și utilizați echipamente de rețea rusești, atunci alegeți unul care acceptă protocoale de flux sau are porturi SPAN/RSPAN.
- Combinați sistemele de detectare/prevenire a intruziunilor/atacurilor la margini și sistemele de analiză a fluxului în rețeaua internă (inclusiv în nori).
În ceea ce privește ultimul sfat, aș vrea să dau o ilustrație pe care am dat-o deja înainte. Vedeți că, dacă anterior serviciul de securitate a informațiilor Cisco și-a construit aproape în întregime sistemul de monitorizare a securității informațiilor pe baza sistemelor de detectare a intruziunilor și a metodelor de semnătură, acum ele reprezintă doar 20% din incidente. Alte 20% cade pe sistemele de analiză a fluxului, ceea ce sugerează că aceste soluții nu sunt un capriciu, ci un adevărat instrument în activitățile serviciilor de securitate a informațiilor unei întreprinderi moderne. Mai mult, aveți cel mai important lucru pentru implementarea lor - infrastructura de rețea, investiții în care pot fi protejate în continuare prin atribuirea funcțiilor de monitorizare a securității informațiilor rețelei.
În mod specific nu am atins subiectul răspunsului la anomalii sau amenințări identificate în fluxurile de rețea, dar cred că deja este clar că monitorizarea nu trebuie să se încheie doar cu detectarea unei amenințări. Ar trebui să fie urmată de un răspuns și, de preferință, într-un mod automat sau automat. Dar acesta este un subiect pentru un articol separat.
Informații Suplimentare:
PS. Dacă îți este mai ușor să auzi tot ce a fost scris mai sus, atunci poți urmări prezentarea de o oră care a stat la baza acestei note.
Sursa: www.habr.com