Sfaturi de bune practici pentru intelligence de amenințare

Mulți oameni spun că intelligence de amenințare (TI) este bun, dar puțini înțeleg cum să îl pregătească. Mai puțini sunt cei care știu care procese să implice pentru ca TI să funcționeze și să aducă profit. Mai mult, un număr neglijabil de oameni știu cum să aleagă un furnizor de feed, unde să verifice indicatorul de false pozitive și dacă este oportun să blocheze un domeniu trimis de un coleg prin WhatsApp.

Aveam două abonamente comerciale APT, zece schimburi de informații, aproximativ o duzină de feed-uri gratuite și o listă extinsă de noduri de ieșire TOR. De asemenea, am folosit câteva reverseri puternice, scripturi Powershell master, un scanner Loki și un abonament plătit VirusTotal. Nu înseamnă că un centru de răspuns la incidente de securitate nu va funcționa fără toate acestea, dar dacă sunteți dispuși să prindeți atacuri complexe, trebuie să faceți tot ce este necesar.

Ceea ce mă îngrijora în mod special era posibilitatea de a automatiza verificarea indicatorilor de compromis (IOCs). Nu există nimic mai imoral decât ca inteligența artificială să înlocuiască un om într-o activitate care necesită gândire. Cu toate acestea, am realizat că compania mea va întâmpina această provocare mai devreme sau mai târziu, pe măsură ce numărul clienților noștri creștea.

În urma a câtorva ani de activitate permanentă de TI, am pășit pe o mulțime de greșeli și aș dori să ofer câteva sfaturi care vor ajuta începătorii să evite greșelile comune.

Sfat 1. Nu puneți prea multe speranțe în capturarea prin hash-uri: majoritatea malware-ului este polimorfic în zilele noastre

Datele de intelligence de amenințare vin în diferite formate și manifestări. Pot include adrese IP ale centrelor de comandă și control ale botnet-urilor, adrese de e-mail implicate în campanii de phishing și articole despre tehnici de evaziune pe care grupurile APT le vor folosi în curând. Pe scurt, acestea pot fi lucruri diferite.

Pentru a clarifica această situație, David Bianco a sugerat utilizarea a ceea ce se numește Piramide a durerii. Aceasta descrie o corelație între diferiții indicatori pe care îi utilizați pentru a detecta un atacator și cantitatea de “durere” pe care o veți cauza atacatorului dacă identificați un anumit IOC.

De exemplu, dacă știți hash-ul MD5 al fișierului malicios, acesta poate fi detectat ușor și precis. Cu toate acestea, nu va cauza prea multă durere atacatorului, deoarece adăugarea a doar 1 bit de informație la acel fișier va schimba complet hash-ul său.

Sfat 2. Încercați să utilizați indicatorii pe care atacatorul îi va găsi tehnico-complicati sau scumpi de schimbat

Anticipând întrebarea cum să aflați dacă un fișier cu un anumit hash există în rețeaua noastră de întreprindere, voi spune următoarea: există diferite moduri. Una dintre cele mai ușoare metode este de a utiliza o soluție care menține o bază de date cu hash-urile MD5 ale tuturor fișierelor executabile din întreprindere.

Să ne întoarcem la Piramida durerii. În contrast cu detectarea prin valoarea hash, este mai productiv să identificați tactica, tehnicile și procedurile (TTP) atacatorului. Acest lucru este mai greu de făcut și necesită mai mult efort, dar veți cauza mai multă durere atacatorului.

De exemplu, dacă știți că grupul APT care vizează sectorul dvs. economic trimite e-mailuri de phishing cu fișiere *.HTA, atunci crearea unei reguli de detectare care caută astfel de atașări de e-mail va lovi atacatorul sub centură. Ei vor trebui să modifice tactica de spam și, poate, să cheltuiască bani pentru a cumpăra exploit-uri 0-day sau 1-day care nu sunt ieftine.

Sfat 3. Nu puneți prea multe speranțe în regulile de detectare create de altcineva, deoarece trebuie să verificați aceste reguli pentru false pozitive și să le ajustați

În timp ce creați reguli de detectare, există întotdeauna o ispită de a utiliza reguli disponibile. Sigma este un exemplu de depozit gratuit. Acesta este un format independent de SIEM pentru metode de detectare care vă permite să traduceți reguli din limbajul Sigma în ElasticSearch, precum și în reguli Splunk sau ArcSight. Depozitul conține sute de reguli. Se pare a fi o chestiune bună, dar diavolul, ca întotdeauna, este în detalii.

Să aruncăm o privire asupra unei reguli de detectare a mimikatz. Această regulă detectează procese care au încercat să citească memoria procesului lsass.exe. Mimikatz face acest lucru atunci când încearcă să obțină hash-uri NTLM, și regula va identifica malware-ul.

Cu toate acestea, este critic pentru noi, experții care nu doar detectează, ci și răspund la incidente, să ne asigurăm că este, de fapt, un actor malicios. Din nefericire, există numeroase procese legitime care citesc memoria lsass.exe (de exemplu, unele unelte antivirus). Prin urmare, într-un scenariu din lumea reală, o regulă de acest fel va cauza mai multe false pozitive decât beneficii.

Nu sunt dispus să acuz pe nimeni în acest sens – toate soluțiile generează false pozitive; este normal. Cu toate acestea, specialiștii în intelligence de amenințare trebuie să înțeleagă că verificarea și ajustarea regulilor obținute din surse deschise și închise este încă necesară.

Sfat 4. Verificați numele de domeniu și adresele IP pentru comportament malicios nu numai la serverul proxy și la focar, ci și în jurnalele serverului DNS – și asigurați-vă că vă concentrați atât pe încercările de rezolvare reușite, cât și pe cele eșuate

Domeniile și adresele IP malicioase sunt indicatorii optimi din perspectiva simplității detectării și a cantității de durere pe care o cauzați atacatorului. Cu toate acestea, ele par a fi ușor de gestionat doar la prima vedere. Cel puțin, ar trebui să vă întrebați unde să obțineți jurnalul de domeniu.

Dacă vă limitați la verificarea jurnalelor serverului proxy, puteți pierde codul malicios care încearcă să interogheze rețeaua direct sau solicită un nume de domeniu inexistent generat cu DGA, fără a mai menționa tunelarea DNS – niciuna dintre acestea nu va fi listată în jurnalele serverului proxy corporativ. Criminalii pot, de asemenea, utiliza servicii VPN cu funcții avansate sau crea tunele personalizate.

Sfat 5. Monitorizați sau blocați – decideți care dintre acestea să alegeți doar după ce ați aflat ce tip de indicator ați descoperit și ați recunoscut consecințele posibile ale blocării

Fiecare expert în securitate IT a întâmpinat o dilemă neînsemnată: să blocheze o amenințare sau să monitorizeze comportamentul acesteia și să înceapă să investigheze odată ce declanșează alerte. Unele instrucțiuni îndeamnă în mod clar să alegeți blocarea, dar uneori face acest lucru este o greșeală.

Dacă indicatorul de compromis este un nume de domeniu utilizat de un grup APT, nu îl blocați – începeți să îl monitorizați în schimb. Tacticile actuale de implementare a atacurilor țintite presupun prezența unui canal de conexiune secret suplimentar, cum ar fi aplicații de urmărire a celularului, care pot fi descoperite doar prin analiza aprofundată. Blocarea automată vă va împiedica să descoperiți acest canal în acest scenariu; în plus, adversarii vor realiza rapid că ați observat manevrele lor.

Pe de altă parte, dacă IOC este un domeniu utilizat de crypto-ransomware, trebuie să fie blocat imediat. Dar nu uitați să monitorizați toate încercările eșuate de a interoga domeniile blocate – configurația encoderului malicios poate include mai multe URL-uri de servere de comandă și control. Unele dintre acestea nu pot fi în feed-uri și, prin urmare, nu vor fi blocate. Mai devreme sau mai târziu, infecția va ajunge la ele pentru a obține cheia de criptare care va fi utilizată imediat pentru a cripta gazda. Singurul mod sigur de a vă asigura că ați blocat toate C&C este de a inversa mostrele.

Sfat 6. Verificați toți noii indicatori pentru relevanță înainte de a îi monitoriza sau bloca

Țineți cont de faptul că datele de amenințare sunt generate de oameni care sunt supuși erorilor, sau de algoritmi de învățare automată care nu sunt infailibili. Am fost martor la furnizori de rapoarte plătite despre activitatea grupurilor APT care au adăugat accidental mostre legitime la listele de hash-uri MD5 malicioase. Având în vedere că chiar și rapoartele plătite de amenințare conțin IOCs de calitate scăzută, cele obținute prin inteligență deschisă ar trebui să fie verificate cu siguranță pentru relevanță. Analistii TI nu verifică întotdeauna indicatorii pentru false pozitive, ceea ce înseamnă că clientul trebuie să facă verificarea pentru ei.

De exemplu, dacă ați obținut o adresă IP utilizată de o nouă iterație a TrickBot, înainte de a o utiliza în sistemele dvs. de detectare, ar trebui să vă asigurați că nu face parte dintr-un serviciu de găzduire sau nu emană de la adresa dvs. IP. Altfel, veți avea o perioadă dificilă cu numeroase false pozitive atunci când utilizatorii care vizitează un site care se află pe acea platformă de găzduire merg la pagini web complet inofensive.

Sfat 7. Automatizați toate fluxurile de lucru ale datelor de amenințare la maximum. Începeți prin a automatiza complet verificarea falselor pozitive prin intermediul unei liste de avertizare, instruind SIEM-ul să monitorizeze IOCs care nu declanșează false pozitive

Pentru a evita un număr mare de false pozitive legate de inteligența și obținute din surse deschise, puteți efectua o căutare preliminară a acestor indicatori în liste de avertizare. Pentru a crea aceste liste, puteți utiliza cele mai bune 1000 de site-uri web după trafic, adresele subrețelelor interne, precum și domeniile utilizate de furnizorii de servicii majore, cum ar fi Google (GOOGL ), Amazon (AMZN ) AWS, MS Azure și altele. De asemenea, este o idee bună să implementați o soluție care modifică dinamic liste de avertizare care constau în cele mai bune domenii / adrese IP pe care angajații companiei le-au accesat în ultima săptămână sau lună.

Crearea acestor liste de avertizare poate fi problematică pentru un SOC de dimensiuni medii, astfel că are sens să luați în considerare adoptarea unor platforme de intelligence de amenințare.

Sfat 8. Scanați întreaga întreprindere pentru indicatori de gazdă, nu doar gazdele conectate la SIEM

De regulă, nu toate gazdele dintr-o întreprindere sunt conectate la SIEM. Prin urmare, este imposibil să le verificați pentru un fișier malicios cu un anumit nume sau cale doar utilizând funcționalitatea standard a SIEM. Puteți rezolva această problemă în următoarele moduri:

1. Utilizați scanere IOC, cum ar fi Loki. Puteți utiliza SCCM pentru a-l lansa pe toate gazdele întreprinderii și apoi a trimite rezultatele într-un dosar de rețea partajat.
2. Utilizați scanere de vulnerabilități. Unele dintre ele au moduri de conformitate care vă permit să verificați rețeaua pentru un anumit fișier într-o anumită cale.
3. Scrieți un script Powershell și rulați-l prin WinRM.

După cum s-a menționat mai sus, acest articol nu este destinat să fie o bază de cunoștințe cuprinzătoare despre cum să faceți corect intelligence de amenințare. În funcție de experiența noastră, totuși, urmând aceste reguli simple, începătorii vor putea evita greșelile critice la manipularea diferiților indicatori de compromis.