Sem hluti af faglegri starfsemi sinni þurfa verktaki, pentesters og öryggissérfræðingar að takast á við ferla eins og Vulnerability Management (VM), (Secure) SDLC.
Undir þessum orðasamböndum liggja mismunandi sett af venjum og verkfærum sem notuð eru sem eru samtvinnuð, þó að notendur þeirra séu mismunandi.
Tækniframfarir eru ekki enn komnar á það stig að eitt tæki getur komið í stað manns til að greina öryggi innviða og hugbúnaðar.
Það er áhugavert að skilja hvers vegna þetta er svona og hvaða vandamál maður stendur frammi fyrir.
Ferlarnir
Varnarleysisstjórnunarferlið er hannað fyrir stöðugt eftirlit með öryggi innviða og plástrastjórnun.
Öruggt SDLC ferlið („örugg þróunarlota“) er hannað til að viðhalda öryggi forrita meðan á þróun og rekstri stendur.
Svipaður hluti af þessum ferlum er varnarleysismatsferlið - varnarleysismat, varnarleysisskönnun.
Helsti munurinn á VM og SDLC skönnun er að í fyrra tilvikinu er markmiðið að greina þekkta veikleika í hugbúnaði eða uppsetningu þriðja aðila. Til dæmis gamaldags útgáfa af Windows eða sjálfgefinn samfélagsstrengur fyrir SNMP.
Í öðru tilvikinu er markmiðið að greina veikleika ekki aðeins í íhlutum þriðja aðila (ósjálfstæði), heldur fyrst og fremst í kóða nýju vörunnar.
Þetta skapar mun á verkfærum og aðferðum. Að mínu mati er verkefnið að finna nýja veikleika í forriti miklu áhugaverðara þar sem það kemur ekki niður á fingrafaraútgáfum, söfnun borða, þvingandi lykilorð o.s.frv.
Fyrir hágæða sjálfvirka skönnun á veikleikum forrita þarf reiknirit sem tekur mið af merkingarfræði forritsins, tilgangi þess og sérstökum ógnum.
Oft er hægt að skipta út innviðaskanni fyrir tímamæli eins og ég orðaði það . Málið er að, eingöngu tölfræðilega, geturðu talið innviði þína viðkvæman ef þú hefur ekki uppfært það, segjum, í mánuð.
Verkfæri
Skönnun, eins og öryggisgreining, er hægt að framkvæma með því að nota annað hvort svartan kassa eða hvítan kassa.
Black Box
Við svartboxaskönnun verður tólið að geta unnið með þjónustuna í gegnum sömu viðmót og notendur vinna með hana.
Innviðaskannar (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose o.s.frv.) leita að opnum netgáttum, safna „borða“, ákvarða útgáfur af uppsettum hugbúnaði og leita í þekkingargrunni þeirra að upplýsingum um veikleika í þessum útgáfum. Þeir reyna einnig að greina stillingarvillur eins og sjálfgefið lykilorð eða opinn gagnaaðgang, veik SSL dulmál osfrv.
Vefforritaskannarar (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP o.s.frv.) geta einnig auðkennt þekkta íhluti og útgáfur þeirra (til dæmis CMS, rammar, JS bókasöfn). Helstu skref skannarsins eru skrið og óljós.
Meðan á skrið stendur, safnar skanninn upplýsingum um núverandi forritaviðmót og HTTP breytur. Meðan á óljósu stendur eru stökkbreytt eða mynduð gögn sett inn í allar greindar breytur til að framkalla villu og greina varnarleysi.
Slíkir forritaskannar tilheyra DAST og IAST flokkunum - Dynamic og Interactive Application Security Testing, í sömu röð.
White Box
Það er meiri munur á whitebox skönnun.
Sem hluti af VM ferlinu er skanna (Vulners, Incsecurity Couch, Vuls, Tenable Nessus o.s.frv.) oft veittur aðgangur að kerfum með því að framkvæma staðfesta skönnun. Þannig getur skanninn sótt uppsettar pakkaútgáfur og stillingarbreytur beint úr kerfinu, án þess að giska á þær af netþjónustuborðum.
Skönnunin er nákvæmari og fullkomnari.
Ef við tölum um skönnun á hvítum kassa (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs o.s.frv.) á forritum, þá erum við venjulega að tala um kyrrstöðugreiningu og notkun viðeigandi verkfæra af SAST-flokknum - Static Application Security Testing.
Vandamál
Það eru mörg vandamál með skönnun! Ég þarf að sinna flestum þeirra persónulega sem hluti af þjónustu við uppbyggingu skönnunar og öruggra þróunarferla, sem og við öryggisgreiningarvinnu.
Ég mun draga fram 3 meginhópa vandamála sem staðfestir eru af samtölum við verkfræðinga og yfirmenn upplýsingaöryggisþjónustu í ýmsum fyrirtækjum.
Vandamál við skönnun á vefforritum
- Erfiðleikar við framkvæmd. Það þarf að dreifa skanna, stilla, sérsníða fyrir hvert forrit, úthluta prófunarumhverfi fyrir skannanir og innleiða í CI/CD ferli til að þetta skili árangri. Annars verður það gagnslaus formleg aðferð sem mun aðeins gefa rangar jákvæðar niðurstöður
- Lengd skanna. Jafnvel árið 2019, vinna skannar lélegt starf við að afrita viðmót og geta eytt dögum í að skanna þúsund blaðsíður með 10 breytum á hverri, miðað við þær ólíkar, þó að sami kóði sé ábyrgur fyrir þeim. Á sama tíma þarf að taka ákvörðun um dreifingu til framleiðslu innan þróunarlotunnar fljótt
- Léleg meðmæli. Skannar gefa nokkuð almennar ráðleggingar og verktaki getur ekki alltaf fljótt skilið af þeim hvernig á að draga úr áhættustigi, og síðast en ekki síst, hvort það þurfi að gera það núna eða er það ekki skelfilegt ennþá
- Eyðileggjandi áhrif á umsóknina. Skannar geta vel framkvæmt DoS árás á forrit og geta líka búið til fjölda aðila eða breytt þeim sem fyrir eru (td búið til tugþúsundir athugasemda á bloggi), svo þú ættir ekki að hefja skönnun í framleiðslu án hugsunar.
- Lítil gæði greiningar á varnarleysi. Skannar nota venjulega fasta burðarfjölda og geta auðveldlega misst af varnarleysi sem passar ekki inn í þekkta hegðun forritsins.
- Skannarinn skilur ekki virkni forritsins. Skannararnir sjálfir vita ekki hvað "netbanki", "greiðsla", "athugasemd" eru. Fyrir þá eru aðeins hlekkir og færibreytur, svo stórt lag af mögulegum viðskiptarógískum varnarleysi er algjörlega afhjúpað; þeim dettur ekki í hug að gera tvöfalda afskrift, njósna um gögn einhvers annars með auðkenni eða auka jafnvægið með námundun
- Skannarinn skilur ekki merkingarfræði síðna. Skannar geta ekki lesið algengar spurningar, þekkja ekki captchas og sjálfir geta þeir ekki fundið út hvernig á að skrá sig og skrá sig svo aftur inn, að þú getur ekki smellt á „útskrá“ og hvernig á að skrifa undir beiðnir þegar breytu er breytt gildi. Þar af leiðandi getur verið að flest forritið sé alls ekki skannað.
Vandamál við að skanna frumkóða
- Falskt jákvætt. Stöðug greining er flókið verkefni sem felur í sér mörg skipti. Oft þarf að fórna nákvæmni og jafnvel dýrir fyrirtækjaskannar framleiða gríðarlegan fjölda falskra jákvæðra
- Erfiðleikar við framkvæmd. Til að auka nákvæmni og fullkomnun kyrrstöðugreiningar er nauðsynlegt að betrumbæta skönnunarreglurnar og getur ritun þessara reglna verið of vinnufrek. Stundum er auðveldara að finna alla staði í kóðanum með einhvers konar villu og laga þá en að skrifa reglu til að greina slík tilvik
- Skortur á framfærslustuðningi. Stór verkefni eru háð miklum fjölda bókasöfnum og ramma sem auka getu forritunarmálsins. Ef þekkingargrunnur skannarsins hefur ekki upplýsingar um "vaskana" í þessum ramma, verður það blindur blettur og skanninn mun einfaldlega ekki einu sinni skilja kóðann
- Lengd skanna. Að finna veikleika í kóða er flókið verkefni hvað varðar reiknirit. Þess vegna gæti ferlið tekið langan tíma og krefst umtalsverðs tölvuauðlinda.
- Lítil þekju. Þrátt fyrir auðlindanotkun og skannatíma þurfa SAST verkfæraframleiðendur enn að gera málamiðlanir og greina ekki öll ríki sem forritið gæti verið í
- Afritunarhæfni niðurstaðna. Það er frábært að benda á tiltekna línu og kallastafla sem leiðir til veikleika, en í raun veitir skanninn oft ekki nægar upplýsingar til að athuga hvort veikleiki sé til staðar utan frá. Þegar öllu er á botninn hvolft gæti gallinn líka verið í dauðum kóða, sem er óaðgengilegur fyrir árásarmann
Vandamál við innviðaskönnun
- Ófullnægjandi birgðir. Í stórum innviðum, sérstaklega þeim sem eru aðskildir landfræðilega, er oft erfiðast að vita hvaða vélar eigi að skanna. Með öðrum orðum, skönnunarverkefnið er nátengt eignastýringarverkefninu
- Léleg forgangsröðun. Netskannar gefa oft margar niðurstöður með göllum sem ekki er hægt að nýta í reynd, en formlega er áhættustig þeirra hátt. Neytandinn fær skýrslu sem er erfitt að túlka og óljóst hvað þarf að leiðrétta fyrst.
- Léleg meðmæli. Þekkingargrunnur skannarsins inniheldur oft aðeins mjög almennar upplýsingar um varnarleysið og hvernig á að laga það, svo stjórnendur verða að vopnast Google. Ástandið er aðeins betra með whitebox skanna, sem geta gefið út ákveðna skipun til að laga
- Handsmíðaðir. Innviðir geta haft marga hnúta, sem þýðir hugsanlega marga galla, skýrslur sem þarf að flokka og greina handvirkt við hverja endurtekningu
- Léleg umfjöllun. Gæði innviðaskönnunar fer beint eftir stærð þekkingargrunns um veikleika og hugbúnaðarútgáfur. Þar sem, , jafnvel markaðsleiðtogarnir hafa ekki alhliða þekkingargrunn og gagnagrunnar ókeypis lausna innihalda mikið af upplýsingum sem leiðtogarnir hafa ekki
- Vandamál með plástra. Algengast er að veikleikar til að laga innviði fela í sér að uppfæra pakka eða breyta stillingarskrá. Stóra vandamálið hér er að kerfi, sérstaklega gamalt kerfi, getur hegðað sér ófyrirsjáanlega vegna uppfærslu. Í meginatriðum verður þú að framkvæma samþættingarpróf á lifandi innviðum í framleiðslu.
Nálganir
Hvernig er hægt að vera?
Ég mun segja þér meira um dæmi og hvernig á að bregðast við mörgum af vandamálunum sem talin eru upp í eftirfarandi hlutum, en í bili mun ég gefa til kynna helstu leiðbeiningar sem þú getur unnið í:
- Söfnun ýmissa skannaverkfæra. Með réttri notkun nokkurra skanna geturðu náð umtalsverðri aukningu á þekkingargrunni og gæðum uppgötvunar. Þú getur fundið enn fleiri veikleika en heildarfjölda allra skannar sem eru opnaðir sérstaklega, á meðan þú getur metið áhættustigið nákvæmari og lagt fram fleiri ráðleggingar
- Samþætting SAST og DAST. Hægt er að auka umfjöllun um DAST og nákvæmni SAST með því að skiptast á upplýsingum á milli þeirra. Frá heimildum er hægt að fá upplýsingar um núverandi leiðir og með DAST er hægt að athuga hvort varnarleysið sé sýnilegt utan frá
- Machine Learning™. Árið 2015 I (og ) um að nota tölfræði til að gefa skönnum innsæi tölvuþrjóta og flýta fyrir þeim. Þetta er örugglega fóður fyrir þróun sjálfvirkrar öryggisgreiningar í framtíðinni.
- Samþætting IAST við sjálfvirkar prófanir og OpenAPI. Innan CI/CD leiðslunnar er hægt að búa til skannaferli sem byggir á verkfærum sem virka sem HTTP umboð og virkniprófum sem vinna yfir HTTP. OpenAPI/Swagger próf og samningar munu gefa skanni þær upplýsingar sem vantar um gagnaflæði og gera það mögulegt að skanna forritið í ýmsum ríkjum
- Rétt uppsetning. Fyrir hvert forrit og innviði þarftu að búa til viðeigandi skannasnið, að teknu tilliti til fjölda og eðli viðmóta og tækni sem notuð er
- Sérsniðin skanni. Oft er ekki hægt að skanna forrit án þess að breyta skannanum. Sem dæmi má nefna greiðslugátt, þar sem hverja beiðni þarf að undirrita. Án þess að skrifa tengi við gáttarsamskiptareglur munu skannarar án vitundar sprengja með beiðnum með rangri undirskrift. Einnig þarf að skrifa sérhæfða skanna fyrir ákveðna tegund galla, s.s
- Áhættustjórnun. Notkun ýmissa skanna og samþættingu við utanaðkomandi kerfi eins og eignastýringu og ógnarstjórnun mun gera kleift að nota margar breytur til að meta áhættustigið, þannig að stjórnendur geti fengið fullnægjandi mynd af núverandi öryggisástandi þróunar eða innviða.
Fylgstu með og við skulum trufla varnarleysisskönnunina!
Heimild: www.habr.com