(mulțumiri lui Sergey G. Brester pentru ideea titlului )
Colegi, scopul acestui articol este de a împărtăși experiența unui an de testare a unui nou tip de soluții IDS bazate pe tehnologii de Decepție.
Pentru a menține coerența materialului, consider că este necesar să începem cu premisele. Așadar, problema este:
- Atacurile direcționate sunt cel mai periculos tip de atacuri, deși proporția lor în totalul amenințărilor este mică.
- Nu s-a găsit încă un mijloc de apărare a perimetrului garantat eficient (sau un complex de astfel de mijloace).
- De obicei, atacurile direcționate se desfășoară în mai multe etape. Trecerea de la perimetru este doar una dintre etapele inițiale, care (puteți să mă ''bateți'' cu pietre) nu implică daune mari pentru ''victimă'', dacă, desigur, nu este vorba despre atacuri DEoS (Destruction of service) (ransomware și altele). Daunele reale încep mai târziu, când activele capturate sunt folosite pentru pivotare și dezvoltarea unui atac ''în adâncime'', iar noi nu am observat asta.
- Având în vedere că începem să suferim pierderi reale doar atunci când infractorii ajung efectiv la obiectivele atacului (servere de aplicații, SGBD-uri, stocare de date, repositoare, elemente de infrastructură critică), este logic că una dintre sarcinile serviciului de securitate informațională este întreruperea atacurilor înainte de a se produce acel eveniment nefericit. Dar pentru a opri ceva, trebuie mai întâi să aflăm despre acel lucru. Și cu cât mai devreme – cu atât mai bine.
- Prin urmare, pentru gestionarea cu succes a riscurilor (adică, reducerea daunelor din atacurile direcționate) este esențial să existe instrumente care să asigure un TTD minim (time to detect – timpul de la imersie până la descoperirea atacului). În funcție de industrie și regiune, această perioadă durează în medie 99 de zile în SUA, 106 zile în regiunea EMEA, 172 de zile în regiunea APAC (M-Trends 2017, A View From the Front Lines, Mandiant).
- Ce oferă piața?
- „Sandbox-uri”. O altă măsură de control preventiv, care este departe de ideal. Există o mulțime de tehnici eficiente de detecție și ocolire a sandbox-urilor sau a soluțiilor de whitelisting. băieții din „latura întunecată” sunt aici în continuare cu un pas înainte.
- UEBA (sisteme de profilare a comportamentului și detectare a anomaliilor) teoretic poate fi foarte eficient. Dar, din punctul meu de vedere, aceasta este o perspectivă pentru viitorul îndepărtat. Practic, este încă foarte costisitor, nesigur și necesită o infrastructură IT și de securitate informațională foarte matură și stabilă, unde există deja toate instrumentele care vor genera date pentru analiza comportamentală.
- SIEM este un instrument bun pentru investigații, dar nu poate identifica și prezenta la timp ceva nou, original, deoarece regulile de corelare sunt aceleași semnături.
- În consecință, a apărut nevoia unui astfel de instrument care să:
- funcționeze cu succes în condiții de perimetru deja compromis,
- detecteze atacuri reușite într-un mod aproape în timp real, indiferent de instrumentele și vulnerabilitățile utilizate,
- să nu depindă de semnături/reguli/scenarii/politici/profiluri și alte chestiuni statice,
- să nu necesite mari volume de date și surse pentru analiză,
- să permită identificarea atacurilor nu ca un anumit risc-scor în urma lucrării ‘cea mai bună din lume, brevetată și, prin urmare, închisă matematică’, care necesită investigații suplimentare, ci practic ca un eveniment binar – ‘Da, suntem atacați’ sau ‘Nu, totul este în regulă’,
- să fie universal, eficient scalabil și realmente implementabil în orice mediu heterogen, indiferent de topologia fizică și logică a rețelei folosite.
La acest rol aspiră acum, așa-numitele, soluții de decepție. Adică soluții bazate pe vechea conceptie a honeypot-urilor, dar cu un nivel complet diferit de implementare. Această temă este clar în ascensiune acum.
Rezultatele Soluțiile de decepție sunt în top 3 strategii și instrumente recomandate pentru utilizare.
Conform raportului Decepția este unul dintre direcțiile principale de dezvoltare a soluțiilor IDS (Sisteme de Detectare a Intrusurilor).
O întreagă secțiune din ultimul , dedicată SCADA, se bazează pe datele unuia dintre liderii acestei piețe, TrapX Security (Israel), ale căror soluții au funcționat deja un an în zona noastră de testare.
TrapX Deception Grid permite construirea și operarea centralizată a IDS-uri distribuite masive, fără a crește povara licențelor și cerințele pentru resurse hardware. De fapt, TrapX este un constructor care permite creare din elementele unei infrastructuri IT existente a unui mare mecanism de detectare a atacurilor la nivel de întreprindere, un fel de „sistem de alarmă” distribuit.
Structura Soluției
În laboratorul nostru, studiem și testăm constant diverse inovații în domeniul securității IT. În prezent, aici sunt desfășurate aproximativ 50 de servere virtuale, inclusiv componentele TrapX Deception Grid.
Așadar, de sus în jos:
- TSOC (TrapX Security Operation Console) – creierul sistemului. Aceasta este consola centrală de control, prin care se realizează configurarea, desfășurarea soluției și toată activitatea zilnică. Deoarece este un serviciu web, poate fi desfășurat oriunde – la margine, în cloud sau la un furnizor MSSP.
- TrapX Appliance (TSA) – server virtual, la care conectăm, printr-un port trunk, subrețelele pe care dorim să le cuprindem în monitorizare. De asemenea, aici „trăiesc” de fapt toate senzorii noștri de rețea.
În laboratorul nostru este desfășurat un TSA (mwsapp1), dar de fapt pot fi multe. Acest lucru poate fi necesar în rețele mari, unde între segmente nu există conectivitate L2 (un exemplu tipic – „Holding și filialele” sau „Sediul central al băncii și sucursalele”) sau dacă în rețea există segmente izolate, de exemplu, SCADA. În fiecare astfel de filială/segment se poate desfășura propriul TSA și îl putem conecta la un TSOC unic, pe care toate informațiile vor fi procesate centralizat. Această arhitectură permite construirea de sisteme de monitorizare distribuite fără a necesita o reorganizare radicală a rețelei sau încălcarea segmentării existente.
De asemenea, pe TSA putem trimite o copie a traficului de ieșire prin TAP/SPAN. În cazul în care se descoperă conexiuni cu botneturi cunoscute, servere de comandă, sesiuni TOR, vom obține și rezultatul în consolă. Acest lucru este gestionat de Network Intelligence Sensor (NIS). În mediu nostru, această funcționalitate este realizată pe firewall, de aceea nu am utilizat-o aici.
- Aplicatii Capcane (Full OS) – honeypoturi tradiționale bazate pe servere Windows. Nu este necesar să fie multe, deoarece sarcina principală a acestor servere este de a oferi servicii IT pentru nivelul următor de senzori sau de a detecta atacuri asupra aplicațiilor de afaceri care pot fi desfășurate în medii Windows. În laboratorul nostru, avem instalat un astfel de server (FOS01)
- Capcane emulate – componenta principală a soluției, care ne permite să creăm un câmp minat foarte dens pentru atacatori, folosind o singură mașină virtuală și să saturăm rețeaua întreprinderii, toate VLAN-urile sale, cu senzorii noștri. Atacatorul vede un astfel de senzor, sau un gazdă fantomă, ca un adevărat PC sau server Windows, server Linux sau alt dispozitiv pe care alegem să i-l arătăm.
Pentru a fi de folos și din curiozitate, am desfășurat „câte una din fiecare specie” – PC-uri Windows și servere de diferite versiuni, servere Linux, bancomate cu Windows embedded, SWIFT Web Access, imprimante de rețea, switch-uri Cisco, camere IP Axis, MacBook-uri, dispozitive PLC și chiar o lampă inteligentă. În total – 13 gazde. În general, vendorul recomandă desfășurarea acestor senzori în proporție de minim 10% din numărul real de gazde. Limita superioară este reprezintată de spațiul de adrese disponibil.Un aspect foarte important este că fiecare astfel de gazdă nu este o mașină virtuală completă, care necesită resurse și licențe. Este o „înșelăciune”, o emulare, un proces pe TSA, care are un set de parametri și o adresă IP. Prin urmare, chiar și cu un singur TSA, putem satura rețeaua cu sute de astfel de gazde fantomă, care vor funcționa ca senzori în sistemul de alarmă. Această tehnologie permite scalarea economică eficientă a conceptului de „honeypots” la nivelul oricărei întreprinderi mari și distribuite.
Aceste gazde, din perspectiva atacatorului, sunt atrăgătoare, deoarece conțin vulnerabilități și par a fi ținte relativ ușoare. Atacatorul vede serviciile disponibile pe aceste gazde și poate interacționa cu ele, atacându-le, folosind instrumente și protocoale standard (smb/wmi/ssh/telnet/web/dnp/bonjour/Modbus etc.). Totuși, utilizarea acestor gazde pentru a dezvolta un atac sau a lansa propriul cod nu este posibilă.
- Combinația acestor două tehnologii (FullOS și capcanele emulate) permite atingerea unei probabilități statistice ridicate ca atacatorul să se confrunte, mai devreme sau mai târziu, cu un element al rețelei noastre de semnalizare. Dar cum putem face ca această probabilitate să fie aproape de 100%?
În luptă intră așa-numitele tokenuri (Deception tokens). Datorită lor, putem include în compunerea IDS-ului nostru distribuit toate PC-urile și serverele disponibile în cadrul întreprinderii. Tokenurile sunt plasate pe PC-urile reale ale utilizatorilor. Este important de înțeles că tokenurile nu sunt agenți care consumă resurse și pot provoca conflicte. Tokenurile sunt elemente informative pasive, o specie de „firimituri” pentru atacator, care îl ghidează în capcană. De exemplu, discurile de rețea conectate, marcajele către panouri de administrare false în browser și parolele salvate pentru acestea, sesiunile salvate ssh/rdp/winscp, capcanele noastre cu comentarii în fișierele hosts, parolele salvate în memorie, acreditivul unor utilizatori inexistenți, fișierele office, deschiderea cărora va activa sistemul și multe altele. Astfel, plasăm atacatorul într-un mediu distorsionat, saturat cu acele vectore de atac care, de fapt, nu reprezintă o amenințare pentru noi, ci, dimpotrivă. Și el nu are posibilitatea să determine unde se află informația adevărată și unde cea falsă. Astfel, nu doar că asigurăm o detecție rapidă a atacului, ci și încetinim considerabil desfășurarea acestuia.
Exemplu de creare a unei capcane de rețea și configurarea tokenurilor. Interfață prietenoasă și fără necesitatea de modificări manuale ale configurațiilor, scripturilor etc.
În mediul nostru, am configurat și plasat o serie de astfel de tokenuri pe FOS01 sub Windows Server 2012R2 și pe un PC de test sub Windows 7. Pe aceste mașini este activat RDP și periodic 'le expunem' în DMZ, unde sunt de asemenea plasate și câteva dintre senzorii noștri (capcane emulate). Astfel, obținem un flux constant de incidente, așa-zis, în mod natural.
Așadar, o scurtă statistică pentru un an:
56 208 – incidente înregistrate,
2 912 – gazde sursă de atacuri detectate.
Hartă interactivă, clicabilă a atacurilor
În acest sens, soluția nu generează un mega-log sau un fir de evenimente pe care trebuie să te străduiești să-l înțelegi. În schimb, soluția clasifică singură evenimentele în funcție de tipurile lor și permite echipei de securitate să se concentreze mai întâi pe cele mai periculoase – atunci când atacatorul încearcă să ridice sesiuni de control (interaction) sau când în traficul nostru apar payload-uri binare (infection).
Toate informațiile despre evenimente sunt citibile și, din punctul meu de vedere, sunt prezentate într-un mod ușor de înțeles, chiar și pentru utilizatorii cu cunoștințe de bază în domeniul securității informației.
Majoritatea incidentelor înregistrate sunt încercări de scanare a hosturilor noastre sau conexiuni unice.
Sau încercări de a forța parole pentru RDP.
Dar au existat și cazuri mai interesante, mai ales când atacatorii au „reușit” să spargă o parolă pentru RDP și au obținut acces în rețeaua locală.
Atacatorul încearcă să execute cod folosind psexec.
Atacatorul a găsit o sesiune salvată, care l-a dus într-o capcană sub forma unui server Linux. Imediat după conectare, cu un set de comenzi deja pregătit, a încercat să șteargă toate fișierele de jurnal și variabilele de sistem corespunzătoare.
Atacatorul încearcă să efectueze o injecție SQL pe o capcană care imită SWIFT Web Access.
Pe lângă aceste atacuri „naturale”, am efectuat și o serie de teste proprii. Unul dintre cele mai ilustrative este testarea timpului de detectare a unui vierme de rețea în rețea. Pentru aceasta, am folosit un instrument de la GuardiCore numit . Acesta este un vierme de rețea care poate infecta Windows și Linux, dar fără o „încărcătură” utilă.
Am desfășurat un centru de comandă local, pe una dintre mașini am lansat primul exemplar al viermului și am primit primul avertisment în consola TrapX în mai puțin de o minută și jumătate. TTD 90 de secunde comparativ cu 106 zile în medie...
Datorită posibilității de integrare cu alte tipuri de soluții, putem trece de la detectarea rapidă a amenințărilor la răspunsul automat la acestea.
De exemplu, integrarea cu sistemele NAC (Controlul Accesului în Rețea) sau cu CarbonBlack va permite deconectarea automată a PC-urilor compromise de la rețea.
Integrarea cu sandbox-uri permite transmiterea automată pentru analiză a fișierelor implicate în atac.
Integrarea cu McAfee
De asemenea, soluția are un sistem încorporat de corelare a evenimentelor.
Dar capacitățile acesteia nu ne-au mulțumit, așa că am integrat-o cu HP ArcSight.
Gestionarea amenințărilor detectate „în comun” este ajutată de sistemul de ticketing încorporat.
Deoarece soluția a fost dezvoltată „de la start” pentru nevoile instituțiilor guvernamentale și sectorului corporativ mare, există, desigur, un model de acces bazat pe roluri, integrare cu AD, un sistem avansat de rapoarte și trigeri (notificări de evenimente), orchestrare pentru structuri mari de holdin sau furnizori MSSP.
În loc de rezumat
Dacă există un astfel de sistem de monitorizare, care, figurativ vorbind, ne acoperă spatele, atunci compromiterea perimetrului este doar începutul. Cel mai important este că apare o oportunitate reală de a lupta împotriva incidentelor de securitate a informației, nu de a ne ocupa de consecințele acestora.
Sursa: habr.com
