As ûnderdiel fan har profesjonele aktiviteiten moatte ûntwikkelders, pentesters en befeiligingsprofessionals omgean mei prosessen lykas Vulnerability Management (VM), (Secure) SDLC.
Under dizze frases binne ferskate sets fan praktiken en ark brûkt dy't meiinoar binne, hoewol har brûkers ferskille.
Technologyske foarútgong hat noch net berikt it punt dêr't ien ark kin ferfange in persoan foar it analysearjen fan de feiligens fan ynfrastruktuer en software.
It is nijsgjirrich om te begripen wêrom't dit sa is, en hokker problemen men te krijen hat.
Prozessen
It proses fan kwetsberensbehear is ûntworpen om ynfrastruktuerfeiligens en patchbehear kontinu te kontrolearjen.
It Secure SDLC-proses ("feilige ûntwikkelingssyklus") is ûntworpen om applikaasjefeiligens te behâlden tidens ûntwikkeling en operaasje.
In ferlykber diel fan dizze prosessen is it proses fan kwetsberensbeoardieling - beoardieling fan kwetsberens, skennen fan kwetsberens.
It wichtichste ferskil tusken skennen binnen VM en SDLC is dat yn it earste gefal it doel is om bekende kwetsberens te finen yn software fan tredden of yn in konfiguraasje. Bygelyks, in ferâldere ferzje fan Windows of de standert mienskipstring foar SNMP.
Yn it twadde gefal is it doel om kwetsberens te ûntdekken net allinich yn komponinten fan tredden (ôfhinklikens), mar foaral yn 'e koade fan it nije produkt.
Dit jout oanlieding ta ferskillen yn ark en oanpak. Yn myn miening is de taak om nije kwetsberens te finen yn in applikaasje folle ynteressanter, om't it net delkomt op ferzjefingerprinting, bannerkolleksje, wachtwurd brute force, ensfh.
Automatysk scannen fan hege kwaliteit fan kwetsberens fan applikaasjes fereasket algoritmen dy't rekken hâlde mei de semantyk fan 'e applikaasje, har doel en spesifike bedrigingen.
De ynfrastruktuer scanner kin faak wurde ferfongen troch in timer, as de . It punt is dat puur statistysk, jo kinne beskôgje jo ynfrastruktuer kwetsber as jo hawwe net bywurke foar, sis, in moanne.
Tools
Scannen, lykas befeiligingsanalyse, kinne wurde útfierd as in swarte doaze as in wyt doaze.
Swarte doas
Mei blackbox-skennen moat it ark mei de tsjinst kinne wurkje fia deselde ynterfaces wêrmei brûkers dermei wurkje.
Ynfrastruktuerscanners (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, ensfh.) sykje iepen netwurkports, sammelje "banners", identifisearje ynstalleare softwareferzjes en sykje har kennisbasis foar ynformaasje oer kwetsberens yn dizze ferzjes. Se besykje ek konfiguraasjeflaters te detektearjen lykas standertwachtwurden of iepenbiere tagong ta gegevens, swakke SSL-sifers, ensfh.
Webapplikaasjescanners (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, ensfh.) kinne ek bekende komponinten en har ferzjes detectearje (bgl. CMS, frameworks, JS-biblioteken). De wichtichste krûpstappen binne krûpen en fuzzen.
Tidens it crawljen sammelt de crawler ynformaasje oer besteande applikaasje-ynterfaces en HTTP-parameters. Tidens fuzzing wurde alle ûntdutsen parameters ferfongen troch mutearre as generearre gegevens om in flater út te lokjen en in kwetsberens te detektearjen.
Sokke applikaasjescanners hearre ta de DAST- en IAST-klassen - respektivelik Dynamic and Interactive Application Security Testing.
Witte fak
Mei whitebox-scannen binne d'r mear ferskillen.
As ûnderdiel fan it VM-proses krije scanners (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, ensfh.) Faak tagong ta systemen troch in autentike scan út te fieren. Sa kin de scanner ynstalleare pakketferzjes en konfiguraasjeparameters direkt fan it systeem downloade, sûnder se te rieden fan netwurktsjinstbanners.
De scan is krekter en folsleiner.
As wy prate oer whitebox-scannen (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, ensfh.)
Problemen
D'r binne in protte problemen mei skennen! Ik moat omgean mei de measten fan harren persoanlik as ûnderdiel fan it leverjen fan in tsjinst foar it bouwen fan skennen en feilige ûntwikkeling prosessen, likegoed as by it útfieren fan feiligens analyze wurk.
Ik sil 3 haadgroepen problemen útlizze, dy't ek wurde befêstige troch petearen mei yngenieurs en haaden fan tsjinsten foar ynformaasjefeiligens yn ferskate bedriuwen.
Problemen mei it scannen fan webapplikaasjes
- Swierrichheid fan útfiering. Scanners moatte wurde ynset, konfigureare, oanpast foar elke applikaasje, in testomjouwing tawiisd foar scans en ymplementeare yn it CI / CD-proses om effektyf te wêzen. Oars sil it in nutteleaze formele proseduere wêze, dy't allinich falske positiven útjaan
- Scan doer. Scanners, sels yn 2019, dogge in minne baan mei it deduplikearjen fan ynterfaces en kinne tûzen siden mei elk 10 parameters dagenlang scannen, se beskôgje se oars, hoewol deselde koade foar har ferantwurdlik is. Tagelyk moat it beslút om yn te setten nei produksje binnen de ûntwikkelingssyklus fluch nommen wurde.
- Mine oanbefellings. Scanners jouwe frij algemiene oanbefellings, en it is net altyd mooglik foar in ûntwikkelder om fluch fan har te begripen hoe't jo it risikonivo kinne ferminderje, en it wichtichste, oft it no krekt dien wurde moat, of it is noch net eng.
- Destruktive ynfloed op 'e applikaasje. Scanners kinne maklik in DoS-oanfal op in applikaasje útfiere, en se kinne ek in grut oantal entiteiten oanmeitsje of besteande wizigje (bygelyks meitsje tsientûzenen opmerkingen op in blog), dus jo moatte net sûnder tinken in scan yn in produkt útfiere.
- Mine kwaliteit fan kwetsberensdeteksje. Scanners brûke typysk in fêste array fan payloads en kinne maklik in kwetsberens misse dy't net past yn har bekende applikaasjegedrach.
- De scanner begrypt de funksjes fan 'e applikaasje net. Scanners sels witte net wat in "ynternetbank", "betelling", "kommentaar" is. Foar har binne d'r allinich keppelings en parameters, dus in enoarme laach fan mooglike kwetsberens foar bedriuwslogika bliuwt folslein ûntdutsen, se sille net riede om in dûbele ôfskriuwing te meitsjen, gegevens fan oare minsken troch ID te peepjen of it lykwicht op te lûken troch ôfrûning
- Misbegryp fan sidesemantyk troch de scanner. Scanners kinne net lêze FAQ, kin net werkenne captchas, se sille net riede troch harsels hoe te registrearjen en dan opnij oanmelde, dat kinst net klikke op "ôfmelde", en hoe te tekenjen fersiken by it feroarjen fan parameter wearden. As gefolch, it grutste part fan 'e applikaasje kin bliuwe unscanned hielendal.
Boarnekoade Scanning Issues
- False positives. Statyske analyze is in komplekse taak dy't in protte kompromissen omfettet. Faak moatte jo krektens opofferje, en sels djoere bedriuwsscanners jouwe in enoarm oantal falske positiven út.
- Swierrichheid fan útfiering. Om de krektens en folsleinens fan statyske analyse te fergrutsjen, is it nedich om de skennenregels te ferfine, en it skriuwen fan dizze regels kin te tiidslinend wêze. Soms is it makliker om alle plakken yn 'e koade te finen mei in soarte fan bug en se te reparearjen dan in regel te skriuwen om sokke gefallen te ûntdekken.
- Gebrek oan ôfhinklikensstipe. Grutte projekten binne ôfhinklik fan in grut oantal bibleteken en kaders dy't de mooglikheden fan 'e programmeartaal útwreidzje. As d'r gjin ynformaasje is oer gefaarlike plakken ("sinks") yn dizze kaders yn 'e kennisbasis fan' e scanner, sil dit in blyn plak wurde, en de scanner sil de koade gewoan net iens begripe.
- Scan doer. It finen fan kwetsberens yn koade is ek in drege taak yn termen fan algoritmen. Dêrom kin it proses goed fertrage wurde en wichtige kompjûterboarnen fereaskje.
- Lege dekking. Nettsjinsteande boarneferbrûk en scanduur, moatte ûntwikkelders fan SAST-ark noch altyd ta kompromissen tafoegje en net alle steaten analysearje wêryn in programma kin wêze.
- It finen fan reproducibility. It oanwizen fan 'e spesifike line en opropstapel dy't liedt ta in kwetsberens is geweldich, mar feitlik leveret de scanner net genôch ynformaasje om te kontrolearjen op in eksterne kwetsberens. Ommers, de flater kin ek wêze yn 'e deade koade, dat is net te berikken foar de oanfaller.
Ynfrastruktuer Scanning Issues
- Net genôch ynventarisaasje. Yn grutte ynfrastruktuer, benammen geografysk skieden, is it faaks it dreechste om út te finen hokker hosts te scannen. Mei oare wurden, de taak fan skennen is nau besibbe oan de taak fan assetbehear
- Slechte prioritearring. Netwurkscanners produsearje faak in protte resultaten mei gebreken dy't yn 'e praktyk net eksploitearje kinne, mar formeel is har risikonivo heech. De konsumint krijt in rapport dat dreech te ynterpretearjen is, en it is net dúdlik wat earst korrizjearre wurde moat
- Mine oanbefellings. De kennisbasis fan 'e scanner befettet faak allinich heul algemiene ynformaasje oer de kwetsberens en hoe't it kin reparearje, sadat admins harsels mei Google moatte wapenje. De situaasje is wat better mei whitebox-scanners, dy't in spesifyk kommando útjaan kinne om te reparearjen
- Handmade. Ynfrastruktueren kinne in protte knooppunten hawwe, wat betsjut dat d'r potinsjeel in protte gebreken binne, rapporten wêrop't by elke iteraasje manueel parseard en analysearre wurde moatte
- Slechte dekking. De kwaliteit fan it scannen fan ynfrastruktuer hinget direkt ôf fan de grutte fan 'e kennisbasis oer kwetsberens en softwareferzjes. wêryn, , sels de merklieders hawwe gjin wiidweidige kennisbasis, en d'r is in protte ynformaasje yn 'e databases fan fergese oplossingen dy't de lieders net hawwe
- Problemen mei patching. Meastentiids is it patchjen fan kwetsberens fan ynfrastruktuer it bywurkjen fan in pakket of it feroarjen fan in konfiguraasjetriem. It grutte probleem hjir is dat it systeem, benammen de legacy ien, ûnfoarspelber kin gedrage as gefolch fan in update. Yn feite sille jo yntegraasjetests moatte útfiere op in live ynfrastruktuer yn produksje.
Benaderingen
Hoe moat it wêze?
Ik gean yn 'e folgjende dielen yn mear detail oer foarbylden en hoe't jo mei in protte fan dizze problemen kinne omgean, mar foar no sil ik de haadgebieten oanjaan wêryn jo kinne wurkje:
- Aggregaasje fan ferskate skennen ark. Mei it juste gebrûk fan meardere scanners kin in signifikante ferheging fan 'e kennisbasis en de kwaliteit fan' e deteksje wurde berikt. Jo kinne noch mear kwetsberens fine as de som fan alle scanners yndividueel rinne, wylst jo it risikonivo krekter kinne beoardielje en mear oanbefellings kinne dwaan
- SAST en DAST yntegraasje. It is mooglik om DAST-dekking en SAST-krektens te fergrutsjen troch ynformaasje tusken har te dielen. Fanút de boarne kinne jo ynformaasje krije oer besteande rûtes, en mei help fan DAST kinne jo kontrolearje oft de kwetsberens fan bûten sichtber is
- Machine Learning™. Yn 2015 I (en ) oer it brûken fan statistiken om scanners de yntuysje fan in hacker te jaan en se te fersnellen. Dit is perfoarst iten foar de ûntwikkeling fan automatisearre feiligensanalyse yn 'e takomst.
- IAST-yntegraasje mei autotests en OpenAPI. Binnen de CI/CD-pipeline is it mooglik om in scanproses te meitsjen basearre op ark dy't wurkje as HTTP-proxy's en funksjonele tests dy't wurkje oer HTTP. OpenAPI / Swagger-tests en kontrakten sille de scanner de ûntbrekkende ynformaasje jaan oer gegevensstreamen, meitsje it mooglik om de applikaasje yn ferskate steaten te scannen
- Korrekte konfiguraasje. Foar elke applikaasje en ynfrastruktuer moatte jo in gaadlik skennenprofyl meitsje, rekken hâldend mei it oantal en de aard fan ynterfaces, de brûkte technologyen
- Oanpassing fan scanner. Faak kin in applikaasje net skansearre wurde sûnder de scanner te wizigjen. In foarbyld is in betellingspoarte dêr't elk fersyk moat wurde ûndertekene. Sûnder it skriuwen fan in ferbining nei it gatewayprotokol, sille scanners sûnder sin pikken op fersiken mei in ferkearde hantekening. It is ek nedich om spesjalisearre scanners te skriuwen foar in spesifyk type gebreken, lykas
- Risiko behear. It brûken fan ferskate scanners en yntegraasje mei eksterne systemen lykas Asset Management en Threat Management sil tastean meardere parameters wurde brûkt om te beoardieljen it nivo fan risiko, sadat it behear kin krije in adekwaat byld fan de hjoeddeiske feiligens steat fan de ûntwikkeling of ynfrastruktuer.
Bliuw op 'e hichte en litte wy de kwetsberensscan fersteure!
Boarne: www.habr.com