ProHoster > Skonimi për cenueshmëri dhe zhvillim i sigurt. Pjesa 1

Skonimi për cenueshmëri dhe zhvillim i sigurt. Pjesa 1

Skonimi për cenueshmëri dhe zhvillim i sigurt. Pjesa 1

Në kuadër të aktivitetit profesional, zhvilluesit, pëntester-at dhe ekspertët e sigurisë përballen shpesh me procese si Management i Vulnerabiliteteve (VM) dhe SDLC-i (i sigurt).
Pas këtyre shprehjeve qëndrojnë grupe të ndryshme praktikash dhe mjeteve të përdorura, të cilat janë të ndërlidhura me njëra-tjetrën, ndonëse përdoruesit e tyre dallojnë.

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

Proceset

Procesi i Management-it të Vulnerabiliteteve ('vulnerabiliteteve') ka për qëllim monitorimin e vazhdueshëm të mbrojtjes së infrastrukturës dhe menaxhimin e patch-ëve.
Procesi i Secure SDLC (' cikli i zhvillimit të sigurt') është i destinuar për të mbështetur sigurinë e aplikacionit gjatë zhvillimit dhe operimit.

NjĂ« pjesĂ« e ngjashme e kĂ«tyre proceseve Ă«shtĂ« procesi i VlerĂ«simit tĂ« Vulnerabiliteteve — skanimi pĂ«r vulnerabilitete.
Dallimi kryesor në skanimin brenda VM dhe SDLC është se në rastin e parë, qëllimi është të zbulohet vulnerabilitetet e njohura në softuerin e jashtëm ose në konfiguracion. Për shembull, një version të vjetër të Windows-it ose një string komuniteti në mënyrë të paracaktuar për SNMP.
Në rastin e dytë, qëllimi është të zbulohet vulnerabilitetet jo vetëm në komponentët e jashtëm (varësive), por më së pari në kodin e produktit të ri.

Kjo krijon dallime në mjete dhe qasje. Sipas mendimit tim, detyra e gjetjes së vulnerabiliteteve të reja në aplikacion është shumë më interesante, pasi nuk kufizohet në fingerprinting të versioneve, mbledhjen e bannerave, dhe provimin e fjalëkalimeve.
Për skanimin cilësor të automatizuar të vulnerabiliteteve të aplikacioneve, janë të nevojshme algoritme që marrin në konsideratë semantikën e aplikacionit, qëllimet e tij dhe kërcënimet specifike.

Një skaner i infrastrukturës mund të zëvendësohet shpesh me një timer, siç shprehet ai avleonov.Kuptimi është se statistikat tregojnë se mund ta konsideroni infrastrukturën tuaj të vulnerueshme nëse nuk e keni përditësuar, le të themi, për një muaj.

Mjetet

Skanimi, si dhe analiza e sigurisë, mund të kryhet si me kutinë e zezë, ashtu edhe me kutinë e bardhë.

Black Box

Me skanimin blackbox, mjeti duhet të jetë në gjendje të punojë me shërbimin përmes atyre ndërfaqeve, me të cilat punojnë përdoruesit.

Skenerët e infrastrukturës (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose etj.) kërkojnë porte të hapura rrjeti, mbledhin "banner-a", përcaktojnë versionet e softuerit të instaluar dhe kërkojnë në bazën e tyre të të dhënave informacione mbi dobësitë në këto versione. Ato gjithashtu përpiqen të zbulojnë gabime konfigurimi, siç janë fjalëkalimet standarde ose hyrje të hapur në të dhëna, cifrime të dobëta SSL etj.

Skenerët e aplikacioneve web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP etj.) gjithashtu dinë të identifikojnë komponentët e njohur dhe versionet e tyre (p.sh., CMS, korniza, bibliotekat JS). Hapat kryesorë të skenerit janë crawling dhe fuzzing.
Gjatë procesit të crawling, skeneri mbledh informacion mbi ndërfaqet ekzistuese të aplikacionit, parametrat HTTP. Gjatë fuzzing, në të gjitha parametrat e zbuluar futen të dhëna të modifikuara ose të gjeneruara me qëllim për të provokuar një gabim dhe zbuluar një dobësi.

KĂ«ta skenerĂ« aplikacionesh i pĂ«rkasin klasave DAST dhe IAST — pĂ«rkatĂ«sisht Dynamic dhe Interactive Application Security Testing.

White Box

Me skanimin whitebox, dallimet janë më të mëdha.
Në kuadër të procesit VM, skenerët (Vulners, Incsecurity Couch, Vuls, Tenable Nessus etj.) shpesh i jepet qasje në sisteme, duke kryer një skan autentik. Kështu, skeneri mund të nxjerrë versionet e instaluara të pakos dhe parametrat e konfigurimit direkt nga sistemi, pa i gjetur ato nga banner-at e shërbimeve rrjetë.
Skanimi bëhet më i saktë dhe më i plotë.

NĂ«se flasim pĂ«r skanimin whitebox (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs etj.) tĂ« aplikacioneve, zakonisht bĂ«het fjalĂ« pĂ«r analizĂ«n statike tĂ« kodit dhe pĂ«rdorimin e mjeteve pĂ«rkatĂ«se tĂ« klasĂ«s SAST — Static Application Security Testing.

Problemet

Ka shumë probleme gjatë skanimit! Me shumicën e tyre përballëm personalisht në kuadër të ofrimit të shërbimit për ndërtimin e proceseve të skanimit dhe zhvillimit të sigurt, si dhe gjatë analizave të sigurisë.

Dua të theksoj 3 grupe kryesore problemesh, të cilat konfirmohen edhe nga bisedat me inxhinierët dhe drejtuesit e shërbimeve të sigurisë në kompani të ndryshme.

Problemet e skanimit të aplikacioneve web

  1. Vështirësia e implementimit. Skenerët duhet të rregullohen, konfigurohen, dhe të personalizohen për çdo aplikacion, të dedikohen mjedise testimi për skanime dhe të integrohen në procesin CI/CD për ta bërë këtë efikas. Në të kundërt, do të jetë një procedurë formale e pavlerë, duke gjeneruar vetëm alarmet e rreme.
  2. Kohëzgjatja e skanimit. Skenerët edhe në 2019 kanë vështirësi në deduplifikimin e ndërfaqeve dhe mund të skanojnë për ditë me radhë mijëra faqe me 10 parametra në secilën, duke i konsideruar ato të ndryshme, edhe pse një kod i vetëm është përgjegjës për to. Në këtë kuptim, vendimi për të çuar në prodhim gjatë ciklit të zhvillimit duhet të merret shpejt.
  3. Rekomandime të pakta. Skenerët japin rekomandime tepër të përgjithshme, dhe nuk është gjithmonë e mundur që zhvilluesi të kuptojë shpejt se si të zvogëlojë nivelin e rrezikut, dhe më kryesorja, nëse duhet ta bëjë këtë menjëherë, apo mund të presë.
  4. Dëmtim i mundshëm i aplikacionit. Skenerët mund të realizojnë një sulm DoS mbi aplikacionin, dhe gjithashtu mund të krijojnë një numër të madh entitetesh ose të modifikojnë ato ekzistuese (p.sh., krijimi i dhjetëra mijëra komenteve në një blog), prandaj nuk duhet ta nisim pa mend skanimin në prodhim.
  5. Cilësi e ulët plotesuese e dobësive. Skenerët zakonisht përdorin një grup të caktuar payload-esh dhe mund të humbasin lehtë një dobësi që nuk përputhet me skenarin e njohur të sjelljes së aplikacionit.
  6. Mungesë kuptimi të funksioneve të aplikacionit nga skenerët. Skenerët vetë nuk e dinë çfarë është një 'internet-bankë', 'pagesë', 'komentar'. Për ta, ekzistojnë vetëm lidhje dhe parametra, kështu që një pjesë e madhe e dobësive të mundshme të logjikës së biznesit mbetet krejtësisht e pabërshëm, ata nuk do të mendojnë për dyfishimin e pagesës, për të parë të dhënat e të tjerëve përmes ID-së, ose për të manipuluar bilancin përmes rrethimit.
  7. Mungesë kuptimi të semantikës së faqeve nga skenerët. Skenerët nuk dinë të lexojnë FAQ, nuk janë në gjendje të njohin captchat, vetë ata nuk do të mendojnë se si duhet regjistruar, dhe që më pas duhet të ri-kyçen, se nuk duhet të klikojnë 'logout', dhe si duhet të nënshkruhen kërkesat gjatë ndryshimit të vlerave të parametrave. Si rezultat, një pjesë e madhe e aplikacionit mund të mbetet krejtësisht e pa skanuar.

Probleme në skanimin e kodit burimor.

  1. Alarmet e rreme. Analiza statike është një detyrë e ndërlikuar, në zgjidhjen e së cilës shpesh duhet të bëhen shumë kompromis. Shpesh duhet të sakrifikohet saktësia, dhe madje skanerat e shtrenjtë enterprise japin një sasi të madhe rasti false.
  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 shkruajtja e këtyre rregullave mund të jetë shumë e punës. Ndonjëherë është më e lehtë të gjesh të gjitha vendet në kod me ndonjë defekt dhe t'i korigjosh ato, sesa të shkruash një rregull për të zbuluar këto raste.
  3. Mungesa e mbĂ«shtetjes pĂ«r varĂ«sitĂ«. Projekte tĂ« mĂ«dha varen nga njĂ« numĂ«r i madh bibliotekash dhe frameworkĂ«sh qĂ« zgjasin mundĂ«sitĂ« e gjuhĂ«s sĂ« programimit. NĂ«se nĂ« bazĂ«n e tĂ« dhĂ«nave tĂ« skanerit nuk ka informacion mbi vendet e rrezikshme (“sinks”) nĂ« kĂ«to framework-e, kjo do tĂ« bĂ«het njĂ« pikĂ« e verbĂ«r, dhe skaneri nuk do ta kuptojĂ« dashur
  4. Kohëzgjatja e skanimit. Gjetja e dobësive në kod është një detyrë e ndërlikuar si në terma algoritmike. Prandaj, procesi mund të zgjasë dhe të kërkojë burime të mëdha të llogaritjes.
  5. Mbulimi i ulët. Pavarësisht konsumit të burimeve dhe kohës së gjatë të skanimit, zhvilluesit e mjeteve SAST shpesh duhet të bëjnë kompromis dhe të analizojnë jo të gjitha gjendjet në të cilat mund të ndodhet programi.
  6. Riprodhueshmëria e gjetjeve. Të dhënat mbi rreshtin e saktë dhe grumbullin e thirrjeve që çojnë në dobësi është e shkëlqyer, por në të vërtetë shpesh skaneri nuk jep informacion të mjaftueshëm për të verifikuar ekzistencën e dobësisë nga jashtë. Pra, defekti mund të jetë në kodin e vdekur, i cili është i papërshkueshëm nga një sulmues.

Problemet e skanimit të infrastrukturës.

  1. Inventarizimi 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 host-e duhet të skanohet. Me fjalë të tjera, detyra e skanimit është ngushtësisht e lidhur me detyrën e menaxhimit të aseteve.
  2. Prioritizimi i dobët. Skanerët e rrjetit shpesh japin shumë rezultate me dobësi, të cilat në praktikë nuk janë të shfrytëzuara, por formalisht niveli i rrezikut të tyre është i lartë. Konsumatori merr një raport të cilin është e vështirë ta interpretojë dhe nuk është e qartë se çfarë duhet të rregullohet fillimisht.
  3. Rekomandime të pakta. Në bazën e njohurive të skanerit shpeshherë ka vetëm informacion të përgjithshëm mbi dobësitë dhe mënyrat e rregullimit të tyre, kështu që administratorët do të duhet të përgatiten për të kërkuar në Google. Situata është pak më e mirë me skanerat whitebox, të cilët mund të japin komandën specifike për të rregulluar.
  4. Punë manuale. Në infrastrukturat e mund të ketë shumë nyje, dhe, për pasojë, shumë dobësi potenciale, raportet e të cilave duhet të shqyrtohen dhe analizohen manualisht në çdo iteracion.
  5. Mbulesë e dobët. Cilësia e skanimit të infrastrukturës varet drejtpërdrejt nga volumi i bazës së njohurive mbi dobësitë dhe versionet e softuerit. Megjithatë, rrethanat tregojnë, madje edhe liderët e tregut nuk kanë një bazë të gjithanshme njohurish, dhe në bazat e zgjidhjeve falas ka shumë informacion që liderët nuk e kanë.
  6. Problemet me patchimin. Më së shpeshti patchimi i dobësive në infrastrukturë përfshin përditësimin e paketave ose ndryshimin e skedarëve të konfiguracionit. Një problem i madh këtu është se sistemi, sidomos ai legacy, mund të sillet në mënyrë të paparashikueshme si rezultat i përditësimit. Në thelb, do të duhet të kryhen teste integruese në infrastrukturën aktive në prodhim.

Qasje.

ÇfarĂ« tĂ« bĂ«jmĂ«?
Rreth mënyrave për të trajtuar shumë nga problemet e përmendura, do të flas në pjesët e ardhshme, por për momentin do të shënoj drejtimele që mund të punohet në:

  1. Agregimi i mjeteve të ndryshme të skanimit. Me përdorimin e duhur të disa skanerëve, mund të arrijmë një rritje të konsiderueshme të bazës së njohurive dhe cilësisë së detektimit. Mund të gjejmë edhe më shumë dobësi se sa gjithsej skanerët e ekzekutuar veçmas, duke vlerësuar në mënyrë më të saktë nivelin e rrezikut dhe duke dhënë më shumë rekomandime.
  2. Integrimi i SAST dhe DAST. Mund të rritet mbulimi DAST dhe saktësia SAST përmes shkëmbimit të informacionit midis tyre. Nga burimet, mund të merret informacion mbi rruget ekzistuese, dhe me ndihmën e DAST mund të kontrollohet nëse dobësia është e dukshme nga jashtë.
  3. MĂ«simi Automatikℱ. NĂ« vitin 2015 unĂ« kam treguar (dhe pĂ«rgjigjesha) pĂ«r pĂ«rdorimin e statistikĂ«s pĂ«r t’i dhĂ«nĂ« skanerĂ«ve intuitĂ«n e hakera, dhe pĂ«r t’i pĂ«rshpejtuar. Ky Ă«shtĂ« patjetĂ«r njĂ« 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ë pipeline-it CI/CD është e mundur të krijohet një proces skanimi duke u bazuar në mjete që funksionojnë si HTTP-proxy, dhe teste funksionale që janë të bazuara në HTTP. Testet dhe kontratat OpenAPI/Swagger do t'i japin skanerit informacionin e nevojshëm për flukset e të dhënave dhe do të mundësojnë skanimin e aplikacionit në gjendje të ndryshme.
  5. Konfigurimi i duhur. Për çdo aplikacion dhe infrastrukturë duhet të krijohet një profil skanimi i përshtatshëm, i cili merr parasysh numrin dhe natyrën e ndërfaqeve, teknologjitë e përdorura.
  6. Personalizimi i skanerve. Shpesh aplikacioni nuk mund të skanohet pa përmirësime të skanerit. Një shembull është gateway i pagesave, ku çdo kërkesë duhet të jetë e nënshkruar. Pa shkruar një konnektor për protokollin e gateway-t, skanerët do të godisnin pa mend kërkesat me nënshkrim të gabuar. Gjithashtu, është e nevojshme të shkruhen skanera të specializuar për lloje specifike të dobësive, siç është Referenca e Drejtpërdrejtë e Objektit të Pasigurt.
  7. Menaxhimi i rrezikut. Përdorimi i skanerve të ndryshëm dhe integrimi me sisteme të jashtme, si Menaxhimi i Pasurive dhe Menaxhimi i Kërcënimeve, do të lejojë përdorimin e shumë parametrave për të vlerësuar nivelin e rrezikut, në mënyrë që drejtoria të mund të marrë një pamje të saktë të gjendjes aktuale të sigurisë së zhvillimit ose infrastrukturës.

Qëndroni të informuar dhe le të shqyrtojmë skanimin e dobësive!

Burimi: habr.com

Bleni hostin e besueshĂ«m pĂ«r faqet me mbrojtje nga DDoS, VPS VDS servera đŸ”„ Bli hostin e besueshĂ«m pĂ«r faqet me mbrojtje nga DDoS, VPS VDS servera | ProHoster