ProHoster > Skajimi për vulnerabilitete dhe zhvillimi i sigurt. Pjesa 1

Skajimi për vulnerabilitete dhe zhvillimi i sigurt. Pjesa 1

Skajimi për vulnerabilitete dhe zhvillimi i sigurt. Pjesa 1

Në kuadrin e profesionit të zhvilluesve, pentesterëve, dhe ekspertëve të sigurisë, shpesh përballen me procese si menaxhimi i dobësive (Vulnerability Management - VM) dhe (Secure) SDLC.
Pas këtyre shprehjeve qëndrojnë grupe të ndryshme praktikash dhe veglash që janë të lidhura mes vete, megjithatë përdoruesit e tyre ndryshojnë.

Teknologjia ende nuk ka arritur që një mjet të zëvendësojë njeriun për analizimin e sigurisë së infrastrukturës dhe softuerit.
ËshtĂ« interesante tĂ« kuptosh pse Ă«shtĂ« kĂ«shtu dhe me cilat probleme pĂ«rballen.

Proceset

Procesi i Menaxhimit tĂ« DobĂ«sive (‘Vulnerability Management’) Ă«shtĂ« i destinuar pĂ«r monitorimin e vazhdueshĂ«m tĂ« sigurisĂ« sĂ« infrastrukturĂ«s dhe menaxhimin e patches.
Procesi i SDLC tĂ« Sigurt (‘Secure SDLC’) Ă«shtĂ« dizajnuar pĂ«r tĂ« mbĂ«shtetur sigurinĂ« e aplikacioneve gjatĂ« zhvillimit dhe operimit.

NjĂ« pjesĂ« e ngjashme e kĂ«tyre proceseve Ă«shtĂ« procesi i VlerĂ«simit tĂ« DobĂ«sive – skanimi pĂ«r dobĂ«si.
Dallimi kryesor në skanimin brenda VM dhe SDLC është se në rastin e parë, qëllimi është të zbulohet dobësitë e njohura në softuerin e tretë apo në konfigurim. Për shembull, një version të vjetëruar të Windows ose një sting komunitare të paracaktuar për SNMP.
Në rastin e dytë, qëllimi është të zbulohet dobësitë jo vetëm në përbërësit e jashtëm (varësitë), por kryesisht në kodin e produktit të ri.

Kjo shkakton dallime në veglat dhe qasjet. Në mendimin tim, detyra e gjetjes së dobësive të reja në një aplikacion është shumë më interesante, pasi nuk reduktohet në përcaktimin e versioneve, grumbullimin e banners, kontrollin e fjalëkalimeve, etj.
Për një skanimin cilësor të automatizuar të dobësive të aplikacioneve nevojiten algoritme që marrin parasysh semantikën e aplikacionit, qëllimet e tij, dhe kërcënimet specifike.

Një skaner infrastrukture shpesh mund të zëvendësohet nga një timer, siç shprehet avleonov. Sens është se, statistikisht, mund të konsideroni infrastrukturën tuaj si të prekur, nëse nuk e keni përditësuar, për shembull, për një muaj.

Mjetet

Skanimi, si dhe analizimi i sigurisë, mund të realizohet si kuti e zezë, ashtu edhe kuti e bardhë.

Black Box

Në skanimin e kutisë së zezë, instrumenti duhet të jetë në gjendje të punojë me shërbimin përmes atyre interfeseve që i përdorin përdoruesit.

SkanerĂ«t e infrastrukturĂ«s (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, etj.) kĂ«rkojnĂ« porta tĂ« hapura tĂ« rrjetit, grumbullojnĂ« ‘banners’, pĂ«rcaktojnĂ« versionet e softuerit tĂ« instaluar dhe kĂ«rkojnĂ« nĂ« bazĂ«n e tĂ« dhĂ«nave pĂ«r informacion mbi dobĂ«sitĂ« nĂ« kĂ«to versione. Gjithashtu, pĂ«rpiqen tĂ« zbulojnĂ« gabimet e konfigurimit, si fjalĂ«kalimet e paracaktuara apo aksesin e hapur nĂ« tĂ« dhĂ«na, dhe algoritmet e dobĂ«ta SSL, etj.

Skanerët e aplikacioneve (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, etj.) gjithashtu dinë të përcaktojnë përbërësit e njohur dhe versionet e tyre (për shembull, CMS, framework, biblioteka JS). Hapat kryesorë të skanerit janë crawling dhe fuzzing.
Gjatë crawling, skaneri grumbullon informacion mbi interfesat ekzistuese të aplikacionit, parametrat HTTP. Gjatë fuzzing, në të gjitha parametrat e zbuluar vendosen të dhëna të modifikuara ose të gjeneruara me qëllim të provokojnë një gabim dhe të zbulojnë një dobësi.

KĂ«ta skanerĂ« aplikacionesh i pĂ«rkasin klasave DAST dhe IAST — pĂ«rkatĂ«sisht Dinamik dhe Interaktiv Testimi i SigurisĂ« sĂ« Aplikacioneve.

White Box

Në skanimin e kutisë së bardhë ka më shumë dallime.
Në kuadrin e procesit VM, skanerët (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, etj.) shpesh u jepet qasje në sistemet, duke kryer një skan të autentifikuar. Kështu, skaneri mund të nxjerrë versionet e instaluara të paketave dhe parametrat e konfigurimit direkt nga sistemi, pa iGuess-ing nga banners e shërbimeve rrjet.
Skanimi bëhet më i saktë dhe më i plotë.

NĂ«se flasim pĂ«r skanimin e kutisĂ« sĂ« bardhĂ« (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, etj.) tĂ« aplikacioneve, zakonisht bĂ«het fjalĂ« pĂ«r analizĂ«n statike tĂ« kodit dhe pĂ«rdorimin e veglave pĂ«rkatĂ«se tĂ« klasĂ«s SAST — Testimi Statik i SigurisĂ« sĂ« Aplikacioneve.

Problemet

Ka shumë probleme me skanimin! Me shumicën e tyre, jam ballur personalisht në kuadër të ofrimit të shërbimit për ndërtimin e proceseve të skanimit dhe zhvillimit të sigurt, si dhe gjatë proceseve të analizës së sigurisë.

Përmend tre grupe kryesore problemesh, të cilat konfirmohen nga bisedat me inxhinierët dhe drejtuesit e shërbimeve të sigurisë në një numër të ndryshëm kompanish.

Problemet e skanimit të aplikacioneve në web

  1. Vështirësia e implementimit. Skanerët duhet të vendosen, konfigurohen, të personalizohen për çdo aplikacion, të caktuara mjedise testimi për skanime dhe të integrohen në procesin CI/CD në mënyrë që të jenë efektiv. Ndryshe, kjo do të jetë një procedurë formale e padobishme, që jep vetëm falsifikime.
  2. Kohëzgjatja e skanimit. Skenerët, edhe në 2019, kanë probleme të mëdha me dedupikimin e ndërfaqeve dhe mund të skanojnë për ditë të tëra një mijë faqe me 10 parametra në secilën, duke i konsideruar ato të ndryshme, ndonëse njësi e njëjtë kodi është përgjegjëse për to. Në të njëjtën kohë, vendimi për të bërë deploy në prodhim brenda ciklit të zhvillimit duhet të merret shpejt.
  3. Rekomandime të kufizuara. Skenerët ofrojnë rekomandime mjaft të përgjithshme, dhe nuk është gjithmonë e lehtë për zhvilluesin të kuptojë shpejt se si t'i ulet niveli i rrezikut, dhe më e rëndësishmja, nëse duhet ta bëjë këtë tani, apo mund të presë.
  4. Ndikim destruktiv në aplikacion. Skenerët mund të kryejnë me lehtësi një sulm DoS ndaj aplikacionit, si dhe mund të krijojnë shumë entitete ose të ndryshojnë ato ekzistuese (për shembull, të krijojnë dhjetëra mijëra komente në një blog), prandaj nuk duhen nisur skanime në prodhim pa menduar.
  5. CilĂ«si e ulĂ«t nĂ« zbulimin e dobĂ«sive. SkenerĂ«t zakonisht pĂ«rdorin njĂ« grup tĂ« caktuar ngarkesash (‘payloads’) dhe mund tĂ« humbin lehtĂ«sisht njĂ« dobĂ«si qĂ« nuk pĂ«rputhet me skenarin e njohur tĂ« sjelljes sĂ« aplikacionit.
  6. Moskuptimi i funksioneve tĂ« aplikacionit nga skeneri. SkenerĂ«t vetĂ« nuk e dinĂ« se çfarĂ« Ă«shtĂ« ‘bankĂ« online’, ‘pagesë’, ‘koment’. PĂ«r ata ekzistojnĂ« vetĂ«m lidhje dhe parametra, kĂ«shtu qĂ« njĂ« pjesĂ« e madhe e mundĂ«sive pĂ«r dobĂ«si tĂ« logjikĂ«s sĂ« biznesit mbetet krejtĂ«sisht jashtĂ« mbulimit, ata nuk do tĂ« mendojnĂ« pĂ«r dyfishimin e pagesave, pĂ«r tĂ« parĂ« tĂ« dhĂ«nat e tĂ« tjerĂ«ve sipas ID-sĂ« ose pĂ«r tĂ« manipuluar bilancin pĂ«rmes rrumbullakimit.
  7. Moskuptimi i semantikĂ«s sĂ« faqeve nga skeneri. SkenerĂ«t nuk dinĂ« tĂ« lexojnĂ« FAQ, nuk dinĂ« tĂ« njohin CAPTCHA, vetĂ« nuk do tĂ« kuptojnĂ« se si duhet tĂ« regjistrohen, dhe se mĂ« pas duhet tĂ« ri-identifikohen, se nuk duhet tĂ« klikojnĂ« ‘logout’, dhe si duhet tĂ« nĂ«nshkruhen kĂ«rkesat kur ndryshojnĂ« vlerat e parametrave. Si rezultat, njĂ« pjesĂ« e madhe e aplikacionit mund tĂ« mbetet krejtĂ«sisht e pa skanuar.

Problemet e skanimit të kodit të burimit

  1. Alarmet e rreme. Analiza statike është një detyrë e vështirë, ku shpeshherë duhet të bëhen shumë kompromise. Shumë herë duhet të sakrifikosh saktësinë, dhe madje edhe skenerët e shtrenjta enterprise japin një numër të madh alarmesh të rreme.
  2. Vështirësia e implementimit. Për të rritur saktësinë dhe plotësinë e analizës statike, është e nevojshme të përmirësohen rregullat e skanimit, dhe shkruajta e këtyre rregullave mund të rezultojë shumë e punës.
  3. Mungesa e mbĂ«shtetjes pĂ«r varĂ«sitĂ«. Projektet e mĂ«dha varen nga njĂ« numĂ«r tĂ« madh bibliotekash dhe frameworkesh, qĂ« zgjasin mundĂ«sitĂ« e gjuhĂ«s sĂ« programimit. NĂ«se nĂ« bazĂ«n e njohurive tĂ« skenerit nuk ka informacion mbi vendet e rrezikshme (‘sinks’) nĂ« kĂ«to frameworke, kjo do tĂ« jetĂ« njĂ« pikĂ« e verbĂ«r, dhe skeneri thjesht nuk do tĂ« kuptojĂ« kodin.
  4. Kohëzgjatja e skanimit. Gjetja e dobësive në kod është një detyrë e ndërlikuar dhe në terma algoritmike. Kështu që procesi mund të zgjat dhe të kërkojë burime të konsiderueshme kompjuterike.
  5. Mbulim i ulët. Pavarësisht konsumit të burimeve dhe kohëzgjatjes së skanimit, zhvilluesit e mjeteve SAST përsëri duhet të bëjnë kompromise dhe të analizojnë jo të gjitha shtetet që mund të ketë programi.
  6. Riprodhueshmëria e gjetjeve. Të tregosh një rresht të veçantë dhe një grumbull thirrjesh që çojnë në një dobësi është e shkëlqyer, por në të vërtetë shpesh skeneri nuk ofron mjaft informacion për të verifikuar nëse ka një dobësi nga jashtë. Mungesa mund të jetë gjithashtu në kodin e vdekur, që është i paarritshëm për sulmuesin.

Problemet e skanimit të infrastrukturës

  1. Inventarizim i pamjaftueshëm. Në infrastrukturat e mëdha, veçanërisht ato gjeografikisht të ndara, shpesh është më e vështirë të kuptohet se cilat hoste duhet të skanohen. Me fjalë të tjera, detyra e skanimit është ngushtë e lidhur me detyrën e menaxhimit të aseteve.
  2. Prioritizim i dobët. Skenerët rrjetë shpesh ofrojnë shumë rezultate me të meta, që në praktikë nuk janë të shfrytëzueshme, por formalisht niveli i rrezikut është i lartë. Konsumatori merr një raport që është e vështirë të interpretohet, dhe nuk është e qartë se çfarë duhet të rregullohet fillimisht.
  3. Rekomandime të kufizuara. Në bazën e njohurive të skenerit shpesh ka vetëm informacion shumë të përgjithshëm mbi dobësinë dhe mënyrat e saj të rregullimit, kështu që administratorët do të duhet të armatosen me Google. Situata është pak më e mirë me skenerët whitebox, të cilët mund të japin një komandë të saktë për rregullimin.
  4. Puna manuale. Në infrastrukturat mund të ketë shumë nyje, e kështu, potencialisht shumë të meta, për raportet në lidhje me të cilat duhet të bëhet analiza manuale në çdo iteracion.
  5. Mbulim i dobët. Cilësia e skanimit të infrastrukturës varet drejtpërdrejt nga volumi i bazës së njohurive për dobësitë dhe versionet e softuerit. Megjithatë, ndodh, madje edhe liderët e tregut nuk kanë një bazë njohurish të plotë, dhe në bazat e zgjidhjeve falas ka shumë informacion që liderët nuk e kanë.
  6. Problemet me patching. Shpeshherë, patching i dobësive në infrastrukturë është një përditësim i paketës ose ndryshim i skedarit të konfigurimit. Një problem i madh këtu është se sistemi, veçanërisht ai legacy, mund të sillet në mënyrë të paparashikueshme si rezultat i përditësimit. Në thelb, do të duhet të bëhen teste integruese në infrastrukturën aktive në prodhim.

Qasjet

ÇfarĂ« tĂ« bĂ«jmĂ«?
Më shumë rreth shembujve dhe mënyrave për t'u përballur me shumicën e problemeve të përmendura, do të flas në pjesët e ardhshme, por për momentin do të përmend drejtime të tjera ku mund të punohet:

  1. Agregimi i instrumenteve të ndryshme të skanimit. Me përdorimin e duhur të disa skanerëve, mund të arrihet një rritje e konsiderueshme e bazës së njohurive dhe cilësisë së detektimit. Mund të gjenden madje edhe më shumë dobësi sesa në total nga të gjithë skanerët e ekzekutuar ndaras, duke mundësuar vlerësimin më të saktë të nivelit të rrezikut dhe shpjegimin e rekomandimeve më të shumta.
  2. Integrimi i SAST dhe DAST. Mund të rritet mbulimi i DAST dhe saktësia e SAST përmes shkëmbimit të informacionit midis tyre. Nga burimet mund të merret informacion mbi rrugët ekzistuese, ndërsa me DAST mund të kontrollohet nëse dobësia është e dukshme nga jasht.
  3. Machine Learningℱ. NĂ« vitin 2015 unĂ« kam folur (dhe ende) flisja pĂ«r pĂ«rdorimin e statistikĂ«s pĂ«r tĂ« dhĂ«nĂ« skanerĂ«ve intuitĂ«n e hackerit dhe pĂ«r t'i pĂ«rshpejtuar. Kjo Ă«shtĂ« pa dyshim ushqim pĂ«r zhvillimin e analizĂ«s automatike tĂ« sigurisĂ« nĂ« tĂ« ardhmen.
  4. Integrimi i IAST me testet automatike dhe OpenAPI. Në kuadër të CI/CD-pipeline është e mundur të krijohet një proces skanimi bazuar në instrumente që funksionojnë si HTTP-proxy dhe teste funksionale që punojnë përmes HTTP. Testet dhe kontratat OpenAPI/Swagger do t'i ofrojnë skanerit informacionin e nevojshëm mbi flukset e të dhënave, duke mundësuar skanimin e aplikacionit në gjendje të ndryshme.
  5. Konfigurimi i duhur. Për çdo aplikacion dhe infrastrukturë duhet krijuar një profil skanimi adekuat, duke marrë parasysh numrin dhe natyrën e ndërfaqeve, teknologjitë e përdorura.
  6. Personalizimi i skanerëve. Shpeshherë, aplikacioni nuk mund të skanohet pa përmirësimin e skanerit. Një shembull është porta e pagesave, në të cilën çdo kërkesë duhet të jetë e nënshkruar. Pa shkruar një lidhës për protokollin e portës, skanerët do të zhvillojnë kërkesa me nënshkrime të gabuara. Gjithashtu, është e nevojshme të shkruhen skanerë të specializuar për llojin e veçantë të dobësive, si p.sh. Insecure Direct Object Reference
  7. Menaxhimi i riskut. Përdorimi i skanerëve të ndryshëm dhe integrimi me sisteme të jashtme, si Asset Management dhe Threat Management, do të lejojë përdorimin e shumë parametrave për vlerësimin e nivelit të rrezikut, në mënyrë që drejtuesit të mund të marrin një pasqyrë të saktë mbi gjendjen aktuale të sigurisë së zhvillimit ose infrastrukturës.

Qëndroni të lidhur dhe le të ndryshojmë skanimin e dobësive!

Burimi: habr.com

Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Bleni hostim tĂ« besueshĂ«m pĂ«r faqe me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster