DAST analisiaren gainbehera

Erakunde askok iturri askotatik biltzen dituzte datuak, hala nola erabiltzaileak, eta gero datu-lakuetan gordetzen dituzte. Gaur egun, datuak dena dira, denbora laburrean datu kopuru handia prozesatzeko gaitasuna ere bai. 

Datuen erabilera beti APIen bidez egiten da. APIek aplikazioaren osagai guztiak elkarrekin mantentzen dituzte eta edozein motatako bezeroentzat, adibidez, erabiltzaileentzat, eskuragarri bihurtzen dituzte. 

Jakina, APIak ez ziren bakarrik etorri. Arkitektura monolitiko tradizionalak beste batzuei eman die lekua, mikrozerbitzuei kasu. Gaur egun dena modularra da. Mikrozerbitzuek edozein aplikazio modular bihurtzen dute eskalagarritasun hobea lortzeko, malgutasun handiagoa eta merkaturatzeko denbora laburragoa lortzeko. 

APIekin konbinatutako mikrozerbitzuak software garapenaren etorkizunekotzat hartzen dira. Hain da egia, non OWASPek bere OWASP TOP 10 ezagunaren API egokitutako bertsioa jarri zuen martxan 2019an. Horregatik, eszenatoki honetan, aplikazioen segurtasunak softwarea sortzeko modu berri honetara egokitu eta eguneratuta egon behar du. 

Azken hamarkadan, aplikazioen segurtasuna ere eboluzionatu egin da segurtasun-proba automatizatu eta espezializatu ezberdinetan. Dena den, badirudi segurtasun-kontrolen bilakaera hori atzeratuta doala, aplikazioen segurtasun-analisi dinamikoarekin (DAST) gertatzen den bezala.

DAST, tipo polita 

DAST analisia web aplikazioetan ahultasun espezifikoak aurkitzeko kutxa beltz tresna "nahiko" automatizatu gisa sortu zen ia teknika bakarrak SAST azterketa eta eskuzko pentesting ziren garaian. DASTak pentesterrei laguntzeko eta SAST tresnetako hutsune batzuk betetzeko promesarekin sortu ziren, hala nola, positibo faltsuak eta eskaneatu denbora murriztea. 

Exekuzio-prozesua oso erraza da: aurrez zehaztutako arau-multzoetatik, HTTP eskaerak bidaltzen ditu web-aplikaziora eta testu-kate batzuk egiaztatzen ditu erantzunetan, ahultasunik dagoen ikusteko. Besterik gabe, DAST analisia pentester bat simulatzen saiatzen da. 

Esan beharrik ez dago pare bat eragozpen nagusi daudela:  

• Positibo faltsuak. Edozein positibo faltsuk eskaneatu ondoren berrikuspen labur bat beharko lukete, triage deritzona. Triatze horrek zibersegurtasun analista baten begi adituak beharko lituzke sarritan eta, aditu batentzat ere, denbora preziatua behar du, eskaneatu osteko urratsak moteldu ditzakeena. 
• Denbora. Eskaneek denbora behar dute exekutatzeko, normalean 30 minututik 2 ordura, edo agian egun batzuk, aplikazioaren tamainaren arabera. Gainera, denbora konfigurazio ona denaren araberakoa izango da. Zenbat eta konfigurazio hobea izan, orduan eta denbora gutxiago beharko da exekutatzeko. Baina eskaneatu aurretiko konfigurazio ona lortzea ez da hain erraza eta gehienetan zibersegurtasun aditu bat ere behar da. 

DAST software garapenaren atzetik dago 

Softwarea garatzeko modua aldatu egin da. DAST gaur egun CI/CD kanalizazioan integratzen da eta, CI/CD inguruneetan, bizkortasuna eta abiadura funtsezkoak dira. Edozein eraikuntzak eta inplementazioak minutu pare bat baino gehiago ez luke behar. 

DAST analisiekin ez da hori gertatzen. Lehen aipatu dugun bezala, DAST eskaneek denbora behar dute exekutatzeko, denbora behar dute aurkikuntzak berrikusteko eta denbora behar dute konfiguratzeko. Baina oztopo hauek ez dira arintasuna eta abiadura oztopatzen duten bakarrak: 

• Aurkikuntza eta arakatzea. DAST tresnen ezaugarri nagusietako bat eskaneatzean aplikazioaren ia txoko guztietan bilatzeko eta nabigatzeko duen gaitasuna da. URLak berridazteko eta estekak jarraitzeko arau heuristiko batzuk aplikatuz, DAST tresnek web aplikazioen azpidomeinu eta atal ugari detektatu eta arakatu ditzakete. Aurkikuntza prozesu honen beste bertsio bat proxyak erabiltzea eta eskaneatzeko amaierako puntu guztiak biltzea da. Baina gaur egun, segurtasuna SDLCn ezkerrera mugitzen ari den bitartean, ezaugarri hauek gabeziatzat har litezke denbora behar dutelako. Zorionez, urteetan zehar DAST tresna gehienek hainbat formatutan eskaneatu beharreko aplikazioen amaierako puntuak zehazteko gaitasuna barne hartu dute. 
• Garatzaileek DAST erabiltzen dute. DevSecOps paradigma berriaren arabera, garatzaileek beren kabuz erabil ditzakete kanalizazioetan dauden tresna batzuk, hala nola segurtasun tresnak, softwarearen garapen prozesuan arintasun handiagoa lortzeko helburuarekin. Garatzaileek beraiek DAST analisi batetik segurtasun-analisi baten ondorioak berrikus ditzakete, horrek garapen-prozesu osoa bizkortuko luke. Teorian. Praktikan, garatzaileek ez dakite beti positibo faltsu bat eta zer ez bereizten, edo segurtasun aditu batek baino denbora gehiago eman behar dute horretan. Eszenatoki honek nabarmen murrizten du DevSecOps taldeek positibo faltsuekiko duten tolerantzia eta segurtasun kontrolekiko konfiantza murrizten du. 

Azkenik, softwarea bera ere aldatu da. Hasieran esan genuen bezala, APIak eta mikrozerbitzuak oraina eta etorkizuna dira, eta DAST oso egokia da haientzat: 

• DASTek ez du frontend-ean dinamikoki sortutako edukirik identifikatzen, eta hori oso ohikoa da gaur egun Javascript esparruen erabilera hedatuagatik, hala nola Angular, React, Next, JQuery, etab. 
• DASTek ez ditu API ahultasun mota batzuk hautematen, IDOR/BOLA adibidez, aplikazioaren negozio-logikako testuingurua behar duelako, hala nola erabiltzaile-rolak eta pribilegioak. 
• DASTek ere zailtasunak ditu babes-horma batzuetatik igarotzeko, hala nola, CSRF aurkako tokenak eta APIetako hainbat autentifikazio/baimen mekanismo tipiko, hala nola OAuth2, SSO eta faktore anitzeko autentifikazioa. Oztopo horietako batzuk gainditzea posible bada ere, eskaneatzea prestatzeko denbora handituko litzateke, eta aplikazio bakoitzak bere konfigurazio pertsonalizatua behar du. 

Nola erabili DAST 2023an eta ez hil nahian? 

Une honetan, nahiko tentagarria da DAST alferrikakoa dela pentsatzea, baina ez da hala. Aurreko gabezia asko DAST beste modu batzuetan erabiliz gaindi daitezke: 

• Berrerabili DAST emaitza errazak aurkitzeko. Zaurgarritasun batzuk azkar eta errazak dira DAST tresnak aurkitzeko eta positibo faltsu nahiko baxua izateko. Adibide batzuk HTTP goiburuak seguruak edo existitzen ez direnak, Cross Site Scripting edo SQLi motaren bat dira. 
• Probatu segurtasun-baldintza espezifikoak. Segurtasun-eskakizunen katalogo bat existitzen bada, DAST analisia proba multzo zehatz bat exekutatzeko erabil liteke aplikazio askotan balio handiko eskakizun horiek egiaztatzeko. 
• Sortu konfigurazio txantiloiak aldez aurretik. Lehen aipatu dugun bezala, zenbat eta konfigurazio hobea izan, orduan eta denbora gutxiago beharko da exekutatzeko. Komeni da denbora inbertitzea antzeko ezaugarriak edo arkitektura duten hainbat aplikazio eskaneatzeko erabil daitezkeen konfigurazioak prestatzeko. Hori eginez gero, ondo egindako konfigurazio bakarrarekin, exekuzio denbora eta positibo faltsuak asko murriztuko lirateke etorkizuneko analisietan. 
• Saihestu eskaneaketa osoak. Aplikazio osoa eskaneatzea denbora luzea izan daiteke eta CI/CD kanalizazioko urrats bakoitzak segundo edo minutu batzuk baino ez ditu iraun behar. Horren ordez, mugatu eskanearen esparrua aplikazioan egindako azken aldaketetara soilik 
• Elikatu DAST eskaneatzeko API bide zehatzekin. Zure tresnak onartzen badu (gomendatua), probatu aztertu nahi dituzun API amaierako puntuak soilik, adibidez, aldaketak dituztenak. Horri esker, % 100eko eskaneatze-estaldura lortuko litzateke pixkanaka CI/CD prozesua moteldu gabe. 
• Exekutatu DAST modu asinkronoan. Eskaneatzea CI/CD zikloaren fase batean hasten bada eta denbora pixka bat hartuko badu, aukera ona izango litzateke, besterik gabe, exekutatu amaitu arte itxaron gabe. Geroago, amaitutakoan, talde arduradunak aurkikuntzak berrikusi edo triage batzuk egin ditzake 

Honetaz gain, DAST tresna oso erabilgarria izaten jarraitzen du edozein pentesterrentzat, izan ere, aplikazio ugaritan sarrera-parametro ugari probatzeko (fuzz) gai da denbora laburrean arau-multzo aldez aurretik zehaztuta, mota asko aurkitzeko aukera ematen dutenak. ahultasunak, hala nola injekzioak eta konfigurazio okerrak. 

DAST tresna batek zer izan behar duen APIetan segurtasun-probak egiteko 

DAST edo antzeko tresnak APIaren segurtasun-probetarako ebaluatzean, zaila izan daiteke zein tresna den aukerarik onena jakitea, beraz, behean erabili beharreko irizpide batzuk daude: 

• Erraz integratzen da CI/CD kanalizazio batean 
• Zer aplikazio mota eskaneatu aukeratzeko aukera ematen dizu: APIa edo web front-endarekin 
• Hainbat API zehaztapen formatu onartzen ditu eskaneatu beharreko API bide zehatzak zehazteko: Postman bildumak, OpenAPI/Swagger, GraphQL introspekzioa, WADL, WSDL, etab. 
• Probatzeko API mota zehatza hautatzeko aukera ematen du: REST, GraphQL, SOAP 
• Aurrez eta ondorengo script-ak definitzeko gaitasuna ematen du, konfigurazio oso zehatzak sortzeko, negozio-logikako ahuleziak detektatzeko 

Laburbilduz 

Softwarea garatzeko modua aldatu egin da, baita softwarea bera ere. Arintasuna eta abiadura edozein SDLCren funtsezko ezaugarriak dira CI/CD kanalizazioak erabiltzearen abantailei esker. APIak edozein software osagai berriren muina bihurtu dira, beraz, aplikazio seguruen sorrera azpiko APIetan ahultasunik ezaren araberakoa da. 

APIak oso erritmo azkarrean probatu eta segurtatu behar dira eta, DAST azterketa horretarako aproposa ez den arren, eskaneen konfigurazioa eta kanalizazioetan integratzeko modua alda daitezke APIak hobeto eta azkarrago aztertzeko. 

AI: itxaropen berri bat 

Post hau ezin da amaitu adimen artifiziala aipatu gabe. 

Egia esan, edozein DAST irtenbideek AI aprobetxatu dezakete artikulu honetan aipatutako eragozpen asko konpontzeko, eta gero batzuk. Adibidez, URL berridazketa adimendunaren bidez aurkikuntza eta nabigazio prozesua hobetzeko erabil liteke, eskaera bikoiztuak edo errepikakorrak saihesteko, positibo faltsuak murrizteko, negozio-logika konplexuen ahuleziak detektatzeko... 

Uste duzu posible dela AI DAST phoenix berpiztuko duen sua bihurtzea? 

Ernesto Rubio , Zibersegurtasuneko aholkularia