În cadrul activităților profesionale, dezvoltatorii, testerii de penetrare și specialiștii în securitate se confruntă cu procese precum Managementul Vulnerabilităților (VM) și SDLC (Secure).
Sub aceste expresii se ascund diferite grupuri de practici și instrumente utilizate, care se întrețes între ele, deși utilizatorii lor diferă.
Progresele tehnologice nu au ajuns încă la punctul în care un singur instrument să poată înlocui omul în analiza securității infrastructurii și a software-ului.
Este interesant de înțeles de ce este așa și cu ce probleme se confruntă.
Procese
Procesul de Management al Vulnerabilităților („vulnerability management”) este destinat monitorizării continue a securității infrastructurii și gestionării patch-urilor.
Procesul Secure SDLC („ciclul de dezvoltare sigur”) este destinat susținerii securității aplicației în timpul dezvoltării și exploatării.
O parte similară a acestor procese este Procesul de Evaluare a Vulnerabilităților – scanarea vulnerabilităților.
Principala diferență în scanarea din cadrul VM și SDLC este că, în primul caz, scopul este de a detecta vulnerabilitățile cunoscute în software-ul terț sau în configurație. De exemplu, o versiune depășită de Windows sau un șir comunitar implicit pentru SNMP.
În cel de-al doilea caz, scopul este de a descoperi vulnerabilitățile nu doar în componentele externe (dependințe), ci, în primul rând, în codul noului produs.
Aceasta generează diferențe în instrumentele și abordările utilizate. În opinia mea, găsirea de noi vulnerabilități în aplicație este semnificativ mai interesantă, deoarece nu se reduce la fingerprinting-ul versiunilor, colectarea bannerelor, testarea parolelor etc.
Pentru o scanare automată de calitate a vulnerabilităților aplicațiilor sunt necesare algoritmi care să ia în considerare semantica aplicației, scopul acesteia și amenințările specifice.
Totuși, un scanner de infrastructură poate fi adesea înlocuit cu un temporizator, cum a exprimat Ideea este că, pur statistic, poți considera infrastructura ta vulnerabilă dacă nu ai actualizat-o, să zicem, de o lună.
Instrumente
Scanarea, la fel ca analiza securității, poate fi efectuată atât ca un black box, cât și ca un white box.
Black Box
În cazul scanării black box, instrumentul trebuie să fie capabil să interacționeze cu serviciul prin aceleași interfețe prin care interacționează utilizatorii.
Scanerele de infrastructură (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose etc.) caută porturi de rețea deschise, colectează "banner-uri", determină versiunile software-ului instalat și caută în baza lor de date informații despre vulnerabilitățile acestor versiuni. De asemenea, încearcă să descopere erori de configurare, cum ar fi parolele implicite sau accesul deschis la date, criptările SSL slabe etc.
Scanerele de aplicații web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP etc.) pot, de asemenea, să identifice componentele și versiunile lor cunoscute (de exemplu, CMS-uri, cadre, biblioteci JS). Principalele etape ale scanner-ului sunt crawling și fuzzing.
În timpul crawling-ului, scanner-ul colectează informații despre interfețele existente ale aplicației și parametrii HTTP. În timpul fuzzing-ului, datele mutate sau generate sunt introduse în toate parametrii descoperiți pentru a provoca o eroare și a descoperi o vulnerabilitate.
Aceste scanere de aplicații se încadrează în clasele DAST și IAST - respectiv Dynamic și Interactive Application Security Testing.
White Box
În cadrul scanării whitebox, diferențele sunt mai multe.
În cadrul procesului VM, scanerele (Vulners, Incsecurity Couch, Vuls, Tenable Nessus etc.) primesc adesea acces la sisteme, realizând un scan autenticat. Astfel, scanner-ul poate extrage versiunile instalate ale pachetelor și parametrii de configurare direct din sistem, fără a le ghici pe baza banner-elor serviciilor de rețea.
Scan-ul devine mai precis și mai complet.
Dacă discutăm despre scanarea whitebox (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs etc.) a aplicațiilor, de obicei, se referă la analiza statică a codului și utilizarea instrumentelor corespunzătoare din clasa SAST - Static Application Security Testing.
Probleme
Există numeroase probleme întâmpinate în timpul scanării! Multe dintre acestea le întâlnesc personal în cadrul serviciului oferit pentru construirea proceselor de scanare și dezvoltare sigură, precum și în timpul lucrărilor de analiză a securității.
Voi evidenția 3 grupuri principale de probleme, care sunt confirmate și de discuțiile purtate cu inginerii și conducătorii serviciilor de securitate informațională din diferite companii.
Probleme de scanare a aplicațiilor web
- Dificultatea implementării. Scannerele trebuie să fie configurate, personalizate pentru fiecare aplicație, să aloce un mediu de testare pentru scanări și să fie integrate în procesul CI/CD pentru a fi eficiente. Altfel, acestea vor deveni o procedură formală inutilă, generând în principal alarme false.
- Durata scanării. Scanerele, chiar și în 2019, au dificultăți în deduplicarea interfețelor și pot scana timp de ore mii de pagini cu 10 parametrii pe fiecare, considerându-le diferite, deși codul care le administrează este același. În același timp, decizia de a desfășura în producție în cadrul ciclului de dezvoltare trebuie luată rapid.
- Recomandări limitate. Scanerele oferă recomandări destul de generale, și nu întotdeauna dezvoltatorul poate înțelege rapid cum să reducă nivelul riscului, iar, cel mai important, dacă trebuie să facă acest lucru chiar acum sau poate aștepta.
- Impact distructiv asupra aplicației. Scanerele pot realiza un atac DoS asupra aplicației și pot genera un număr mare de entități sau modifica cele existente (de exemplu, pot crea zeci de mii de comentarii pe un blog), așa că nu ar trebui să lansăm scanări în producție fără o bună planificare.
- Calitate scăzută a detectării vulnerabilităților. Scanerele folosesc de obicei un set fix de payload-uri și pot omite cu ușurință o vulnerabilitate care nu se încadrează în scenariul lor cunoscut de comportament al aplicației.
- Neînțelegerea funcțiilor aplicației de către scanner. Scanerele în sine nu știu ce este un „internet banking”, „plată” sau „comentariu”. Pentru ele există doar linkuri și parametri, așa că un întreg segment de vulnerabilități ale logicii de business rămâne complet nesupravegheat; nu vor deduce o dublare a plății, nu vor putea vizualiza datele altora după ID sau să ajusteze soldul prin rotunjire.
- Neînțelegerea semanticiilor paginilor de către scanner. Scanerele nu pot citi FAQ-uri, nu recunoaște CAPTCHA-uri, în mod individual nu vor înțelege cum să se înregistreze și că ulterior trebuie să se reconecteze, că nu trebuie să apese pe „logout” și cum să semneze cererile când modifică valorile parametrilor. Ca rezultat, o mare parte din aplicație poate rămâne complet nescanată.
Probleme cu scanarea codului sursă.
- Alarme false. Analiza statică este o sarcină complexă, în rezolvarea căreia este necesar să se recurgă la numeroase compromisuri. Adesea, este necesar să se sacrifice precizia, iar chiar și cele mai costisitoare scanere enterprise produc o cantitate mare de fals pozitive.
- Dificultatea implementării. Pentru a crește precizia și acuratețea analizei statice, este necesar să se îmbunătățească regulile de scanare, iar redactarea acestor reguli poate fi prea laborioasă. Uneori, este mai simplu să găsești toate locurile din cod cu o anumită eroare și să le corectezi, decât să scrii o regulă pentru a detecta astfel de cazuri.
- Lipsa suportului pentru dependențe. Proiectele mari depind de un număr mare de biblioteci și cadre care extind capabilitățile limbajului de programare. Dacă în baza de cunoștințe a scanner-ului nu există informații despre locurile periculoase („sinks”) din aceste cadre, acest lucru va deveni un unghi mort, iar scannerul pur și simplu nu va înțelege codul.
- Durata scanării. Căutarea vulnerabilităților în cod este o sarcină complexă și din punct de vedere al algoritmilor. Prin urmare, procesul poate dura mult timp și poate necesita resurse computaționale semnificative.
- Acoperire scăzută. În ciuda consumului de resurse și a duratei scanării, dezvoltatorii instrumentelor SAST sunt nevoiți să recurgă la compromisuri și să nu analizeze toate stările în care poate fi programul.
- Reproducibilitatea descoperirilor. Indicația privind linia specifică și stiva de apeluri care duc la vulnerabilitate este excelentă, dar adesea scannerul nu oferă suficiente informații pentru a verifica existența vulnerabilității din afară. De fapt, defecțiunea poate fi în codul mort, care este inaccesibil atacatorului.
Probleme de scanare a infrastructurii.
- Inventariere insuficientă. În infrastructuri mari, în special cele geografic dispersate, este adesea cel mai greu să înțelegi ce găzduiri trebuie scanate. Cu alte cuvinte, sarcina de scanare este strâns legată de sarcina de management al activelor.
- Priorizare slabă. Scanerele de rețea oferă adesea multe rezultate cu deficiențe care în practică nu sunt exploatabile, dar formal nivelul lor de risc este ridicat. Consumatorul primește un raport care este greu de interpretat și nu este clar ce trebuie corectat mai întâi.
- Recomandări limitate. În baza de cunoștințe a scannerului există adesea doar informații foarte generale despre vulnerabilitate și metodele de remediere, așa că administratorii vor trebui să își folosească Google-ul. Situația este puțin mai bună cu scannerii whitebox, care pot oferi o comandă specifică pentru corectare.
- Lucru manual. În infrastructuri pot exista multe noduri, ceea ce înseamnă că pot exista multe vulnerabilități, iar rapoartele trebuie analizate manual la fiecare iterație.
- Acoperire slabă. Calitatea scanării infrastructurii depinde direct de volumul bazei de cunoștințe despre vulnerabilități și versiunile software-ului. În acest sens, , chiar și la liderii de pe piață, baza de cunoștințe nu este cuprinzătoare, iar în bazele de soluții gratuite există multe informații care nu se regăsesc la lideri.
- Probleme cu patching-ul. Cel mai frecvent, patching-ul vulnerabilităților din infrastructură presupune actualizarea unui pachet sau modificarea unui fișier de configurare. O mare problemă aici este că sistemul, mai ales cel legacy, poate reacționa imprevizibil ca rezultat al actualizării. Practic, va trebui să se efectueze teste de integrare pe infrastructura activă în producție.
Abordări.
Ce să facem?
Mai multe exemple și soluții pentru multe dintre problemele menționate vor fi discutate în părțile următoare, iar acum voi indica principalele direcții în care se poate lucra:
- Agregarea diverselor instrumente de scanare. Dacă sunt utilizate corect, mai multe scanere pot duce la o creștere semnificativă a bazei de cunoștințe și a calității detectării. Se pot găsi chiar mai multe vulnerabilități decât suma tuturor scannerelor rulate separat, iar riscul poate fi evaluat mai precis, oferind mai multe recomandări.
- Integrarea SAST și DAST. Se poate crește acoperirea DAST și precizia SAST prin schimbul de informații între ele. Din sursele de cod se pot obține informații despre rutele existente, iar DAST poate verifica dacă vulnerabilitatea este vizibilă din exterior.
- Machine Learning™. În 2015 am abordat aplicarea statisticilor pentru a oferi scannerelor intuiția unui hacker și a le accelera. Aceasta este, fără îndoială, un subiect de dezvoltare pentru analiza automată a securității în viitor. Volume Provisioning .
- Integrarea IAST cu autotestele și OpenAPI. În cadrul pipeline-ului CI/CD, este posibil să creați un proces de scanare bazat pe instrumente care funcționează ca HTTP proxy și teste funcționale care operează prin HTTP. Testele și contractele OpenAPI/Swagger vor oferi scannerului informațiile lipsă despre fluxurile de date și vor permite scanarea aplicației în diferite stări.
- Configurare corectă. Pentru fiecare aplicație și infrastructură, este necesar să se creeze un profil de scanare adecvat care să țină cont de numărul și natura interfețelor, precum și de tehnologiile utilizate.
- Personalizarea scannerelor. Adesea, aplicația nu poate fi scanată fără modificări la scanner. Un exemplu este poarta de plată, unde fiecare cerere trebuie să fie semnată. Fără scrierea unui conector pentru protocolul porții, scanerele vor trimite fără discernământ cereri cu semnături greșite. De asemenea, este necesar să se scrie scanere specializate pentru anumite tipuri de vulnerabilități, cum ar fi
- Managementul riscurilor. Utilizarea diverselor scanere și integrarea cu sisteme externe, cum ar fi Managementul activelor și Managementul amenințărilor, va permite utilizarea unei varietăți de parametri pentru evaluarea nivelului de risc, astfel încât conducerea să poată obține o imagine adecvată a stării de securitate în dezvoltare sau infrastructură.
Rămâneți conectați și să descurajăm scanarea vulnerabilităților!
Sursa: habr.com
