Professionaalsetes tegevustes seisavad arendajad, testijad ja turbeeksperdid silmitsi selliste protsessidega nagu Vulnerability Management (VM) ja (Secure) SDLC.
Nende fraaside alla kuuluvad erinevad praktikate ja kasutatavate tööriistade kogumid, mis on omavahel seotud, kuigi nende tarbijad on erinevad.
Tehniline areng ei ole veel jõudnud sinnani, et üks tööriist suudaks asendada inimest infrastruktuuri ja tarkvara turvaanalüüsi tegemisel.
On huvitav mõista, miks see nii on, ja milliste probleemidega tuleb silmitsi seista.
Protsessid
Vulnerability Management ("haavatavuste haldamine") protsess on mõeldud infrastruktuuri turvalisuse pidevaks jälgimiseks ja patšihalduseks.
Secure SDLC ("turvalise arenduse tsükkel") protsess toetab rakenduse turvalisust arendamise ja kasutamise käigus.
Nende protsesside sarnane osa on Vulnerability Assessment — haavatavuste hindamine ja skaneerimine.
Peamine erinevus VM-i ja SDLC skaneerimise vahel on see, et esimesel juhul on eesmärk tuvastada tuntud haavatavusi kolmanda osapoole tarkvaras või konfigureerimises. Näiteks aegunud Windowsi versioon või SNMP vaikimisi ühendusstring.
Teisel juhul on eesmärk avastada haavatavusi mitte ainult kolmandate osapoolte komponentides (sõltuvustes), vaid eelkõige uue toote koodis.
See toob kaasa erinevused tööriistades ja lähenemistes. Minu arvates on uute haavatuste leidmise ülesanne rakenduses oluliselt huvitavam, kuna see ei piirdumise versioonide sõrmejälgede, bännerite kogumise, paroolide proovimise jne tegemisega.
Kvaliteetse automaatse rakenduste haavatavuste skaneerimise jaoks on vajalikud algoritmid, mis arvestavad rakenduse semantikat, selle otstarvet ja spetsiifilisi ohte.
Infrastruktuuri skännerit saab tihti asendada taimeriga, nagu ütles . Idee on selles, et statistiliselt võite pidada oma infrastruktuuri haavatavaks, kui te seda ei ole, ütleme, kuu aega värskendanud.
Tööriistad
Skaneerimist, nagu ka kaitseanalüüsi, saab teostada nii musta kasti kui ka valge kasti meetodil.
Musta kasti
Blackbox-skaneerimise käigus peab tööriist olema võimeline töötama teenusega läbi samade liideste, mida kasutavad ka kasutajad.
Infrastruktuuri skanerid (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose jne) otsivad avatud võrguportte, koguvad "bänne", määravad installitud tarkvara versioone ja otsivad oma teadmusbaasist teavet nende versioonide haavatavuste kohta. Samuti üritavad nad tuvastada konfiguratsioonivigu, nagu vaikimisi paroolid või avatud juurdepääs andmetele, nõrgad SSL-šifrid jne.
Veebirakenduste skanerid (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP jne) suudavad samuti tuvastada tuntud komponente ja nende versioone (näiteks CMS, raamistikud, JS-raamatukogud). Skaneerimise põhietapid on kraulimismeetod ja fuzzing.
Kraulimise käigus kogub skaneerija teavet olemasolevate rakenduse liideste ja HTTP-parameetrite kohta. Fuzzingu käigus sisestatakse kõikidesse avastatud parameetritesse muundatud või genereeritud andmed, et provotseerida viga ja tuvastada haavatavus.
Sellised rakenduste skannerid kuuluvad klassidesse DAST ja IAST — vastavalt Dynaamiline ja Interaktiivne Rakenduse Turvalisuse Testimine.
Valge karp
Valge karbi skaneerimise käigus on erinevusi rohkem.
VM-skanerite protsessi raames (Vulners, Incsecurity Couch, Vuls, Tenable Nessus jne) antakse sageli süsteemidele ligipääs, läbiviies autentitud skannimist. Nii saavad skannerid tõmmata välja installitud pakettide versioonid ja konfigureerimisparameetrid otse süsteemist, mitte ei ürita neid arvata võrguteenuste bänneritest.
Skannimine on täpsem ja täielikum.
Kui rääkida whitebox-skannimisest (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs jne) rakendustes, siis toimub tavaliselt staatiline koodi analüüs ja kasutatakse vastavaid SAST (Static Application Security Testing) tööriistu.
Probleemid
Skannimisega tekib palju probleeme! Enamiku nendega pean isiklikult silmitsi seisma seoses skannimisprotsesside ja turvalise arenduse teenuse pakkumisega ning ka turvalisuse analüüsi käigus.
Numble 3 peamist probleemigruppi, mis on kinnitatud vestlustes inseneride ja IT-teenuste juhtidega erinevates ettevõtetes.
Veebirakenduste skannimise probleemid
- Rakendamise keerukus. Skannere tuleb konfigureerida ning kohandada igale rakendusele, eraldada testi keskkond skannide jaoks ja integreerida need CI/CD protsessi, et nad oleksid efektiivsed. Vastasel juhul on see kasutu formaalne protseduur, mis annab ainult valehäireid.
- Skannimise kestus. Skannereid isegi 2019. aastal haldus halbu tulemusi liidese deduplikatsioonis ja nad võivad päeva jooksul skannida tuhande lehte igaühega 10 parameetriga, pidades neid erinevateks, kuigi sama koodi eest vastutab üks ja sama kood. Samas tuleb arendustsükli raames teha kiire otsus, kas viia see produktsiooni.
- Püüdlikud soovitused. Skannereid pakuvad üsna üldisi soovitusi, ja mitte alati ei suuda arendaja neist kiiresti aru saada, kuidas riski vähendada, ning mis kõige olulisem, kas seda tuleb teha kohe või mitte.
- Demonstreeriv mõju rakendusele. Skannereid võivad täiesti tekitada DoS-rünnaku rakendusele, samuti võivad nad luua palju üksuseid või muuta olemasolevaid (näiteks luua kümneid tuhandeid kommentaare blogis), seega ei ole mõistlik skanni arenduses ilma mõtlemata käivitada.
- Madala kvaliteet haavatavuste tuvastamises. Skannerid kasutavad tavaliselt fikseeritud kasulike laadide ('payloads') kogumit ja võivad kergesti jätta avastamata haavatavuse, mis ei vasta nende tuntud rakenduse käitumise stsenaariumile.
- Skanneri arusaam rakenduse funktsioonidest. Skannerid ei tea iseenesest, mis on 'internetipank', 'makse', 'kommentaar'. Neile eksisteerivad vaid lingid ja parameetrid, mistõttu jääb suur osa potentsiaalsetest äri-logika haavatavustest täiesti katmata; nad ei suuda arvata, et tehingut võib kahekordistada, teiste andmeid ID järgi piiluda või tasakaalu suurendada ümardamise kaudu.
- Skanneri arusaam lehtede semantika osas. Skannerid ei oska lugeda FAQ-sid, nad ei tunne ära captcha-te, nad ei suuda iseseisvalt aru saada, kuidas registreeruda, ning et pärast seda on vaja uuesti sisse logida, et mitte vajutada 'logout' ja kuidas tuleb nõudeid allkirjastada parameetrite väärtuste muutmisel. Tulemuseks võib suurem osa rakendusest jääda üldse skanneerimata.
Allika koodi skaneerimise probleemid.
- Valehäired. Staatiline analüüs on keeruline ülesanne, mille lahendamiseks tuleb teha mitmeid kompromisse. Tihti tuleb ohverdada täpsus, ning isegi kallid ettevõtte skannerid toovad välja tohutult valehäireid.
- Rakendamise keerukus. Staatilise analüüsi täpsuse ja põhjalikkuse suurendamiseks on vajalik kohandada skaneerimisreegleid, mis võivad osutuda liiga töömahukaks. Mõnikord on lihtsam leida kõik koodis olevad vead ja need parandada, kui kirjutada reegel nende olukordade tuvastamiseks.
- Riigitegevuse ja võimaluste puudumine. Suured projektid sõltuvad suurest hulgast raamatukogudest ja raamistikest, mis laiendavad programmeerimiskeele võimalusi. Kui skanneri teadmistebaasis pole teavet nendes raamistikest ohtlike kohtade ("sinks") kohta, muutub see pimedaks kohaks, ja skanner ei saa koodi aru.
- Skannimise kestus. Koodis haavatavuste leidmine on keeruline ülesanne ka algoritmide osas. Seega võib protsess kesta kaua ja vajada märkimisväärseid arvutusressursse.
- Madala katvuse tase. Vaatamata ressursside tarbimisele ja skannimise kestusele peavad SAST-tööriistade arendajad siiski leppima kompromissidega ning analüüsima mitte kõiki olekuid, milles programm võib olla.
- Leidude korduvus. Viitamist konkreetsele reale ja kutsungite virnale, mis toob esile haavatavuse — see on suurepärane, kuid tegelikult annab skanner sageli liiga vähe teavet, et väljastpoolt haavatavust kontrollida. Lõppkokkuvõttes võib puudus olla ka surnud koodis, mis on ründajale kättesaamatuks jäänud.
Infrastruktuuri skannimise probleemid
- Ebapiisav inventuur. Suures infrastruktuuris, eriti geograafiliselt jaotatuna, on sageli kõige keerulisem mõista, milliseid hostsse skannida. Teisisõnu, skannimise ülesanne on tihedalt seotud vara haldamise ülesandega.
- Halb prioriteetimine. Võrguskannerid annavad sageli palju tulemusi puudustega, mida praktikas ei eksplekteerita, kuid ametlikult on nende riskitase kõrge. Tarbija saab aruande, mida on raske tõlgendada, ja ei ole selge, mida kõigepealt parandada.
- Püüdlikud soovitused. Teadmiste baasis skanneri kohta on sageli ainult väga üldine teave haavatavuste ja nende parandamise meetodite kohta, mistõttu peavad administraatorid relvastuma Google'iga. Olukord on veidi parem whitebox-skanneritega, mis võivad anda konkreetse käsu parandamiseks.
- Käsitöö. Infrastruktuurides võib olla palju sõlmi, seega võivad olla potentsiaalselt palju vigu, mille aruandeid tuleb iga kord käsitsi analüüsida ja uurida.
- Halb katvus. Infrastruktuuri skaneerimise kvaliteet sõltub otseselt haavatavuste ja tarkvaraversioonide teadmiste baasi mahust. Sellega, , isegi turuliidritel ei ole kõikehõlmavat teadmiste baasi ja tasuta lahenduste baases on palju teavet, mida liidritel pole.
- Probleemid plaastrite rakendamisega. Enamasti on haavatavuste plaastrite rakendamine infrastruktuuris paketide uuendamine või konfigureerimisfaili muutmine. Suur probleem on see, et süsteem, eriti pärand, võib uuendamise tõttu ettearvamatult käituda. Sisuliselt on vaja teha integreerimisteste elavas infrastruktuuris tootmises.
Lähtepunktid.
Kuidas edasi tegutseda?
Rohkem näidete ja kuidas paljude nimetatud probleemidega tegeleda, räägin järgmistes osades, aga praegu toon välja peamised suunad, mille kallal töötada:
- Erinevate skaneerimistööriistade agregatsioon. Õige kasutamise korral mitme skanneriga on võimalik märgatavalt suurendada teadmistepinda ja detekteerimise kvaliteeti. Saame leida isegi rohkem haavatavusi, kui kõik skannerid kokku, mis töötavad eraldi, samas suudame täpsemalt hinnata riski taset ja anda rohkem soovitusi.
- SAST-i ja DAST-i integreerimine. DAST-i katvust ja SAST-i täpsust saab suurendada info vahetamise kaudu nende vahel. Koodiallikatest saab teavet olemasolevate marsruutide kohta ja DAST-i abil saab kontrollida, kas haavatavus on väljastpoolt nähtav.
- Masinõpe™. Aastal 2015 ma (ja ) rääkisin statistika rakendamisest skannerite hackeri intuitsiooni andmiseks ja nende kiirendamiseks. See on kindlasti toit automaatse turvaanalüüsi arendamiseks tulevikus.
- IAST-i integreerimine automaatsete testidega ja OpenAPI-ga. CI/CD-pipeline'i raames on võimalik luua skaneerimisprotsess HTTP-proksi tööriistade ja HTTP-põhiste funktsionaalsete testide abil. Testid ja OpenAPI/Swaggeri lepingud annavad skannerile puuduvat teavet andmevoogude kohta, võimaldades rakendust erinevates seisundites skaneerida.
- Õige konfiguratsioon. Iga rakenduse ja infrastruktuuri jaoks on vajalik luua sobiv skaneerimisprofiil, mis arvestab liideste arvu ja iseloomu ning kasutatavaid tehnoloogiaid.
- Skannerite kohandamine. Sageli ei saa rakendust skaneerida ilma skanneri kohandamiseta. Näiteks maksegateway, kus iga päring peab olema allkirjastatud. Ilma gateway protokolli ühenduse kirjutamiseta püüavad skannerid meeleheitlikult saata vale allkirjaga päringuid. Samuti on vaja kirjutada spetsialiseeritud skannerid teatud puuduste, nagu.
- Riskijuhtimine. Erinevate skannerite kasutamine ja integreerimine väliste süsteemidega, nagu varahaldus ja ohuhaldus, võimaldab riskitaseme hindamiseks kasutada mitmeid parameetreid, nii et juhtkond saab adekvaatse ülevaate arenduse või infrastruktuuri praegusest turvalisusest.
Jätkake jälgimist ja häkkime koos haavatavuste skannimise!
Allikas: habr.com
