Oma kutsetegevuse osana peavad arendajad, testijad ja turbespetsialistid tegelema selliste protsessidega nagu haavatavuse haldus (VM), (turvaline) SDLC.
Nende fraaside all on erinevad praktikad ja kasutatud tööriistad, mis on omavahel läbi põimunud, kuigi nende kasutajad on erinevad.
Tehnoloogiline areng pole veel jõudnud nii kaugele, et üks tööriist saaks asendada inimest infrastruktuuri ja tarkvara turvalisuse analüüsimisel.
Huvitav on mõista, miks see nii on ja milliste probleemidega tuleb silmitsi seista.
Protsessid
Haavatavuse halduse protsess on loodud infrastruktuuri turvalisuse ja paigahalduse pidevaks jälgimiseks.
Turvaline SDLC protsess ("turvaline arendustsükkel") on loodud rakenduste turvalisuse säilitamiseks arendamise ja töötamise ajal.
Sarnane osa nendest protsessidest on haavatavuse hindamise protsess – haavatavuse hindamine, haavatavuse skannimine.
Peamine erinevus VM-is ja SDLC-s skaneerimise vahel on see, et esimesel juhul on eesmärk leida teadaolevad haavatavused kolmanda osapoole tarkvaras või konfiguratsioonis. Näiteks Windowsi aegunud versioon või SNMP vaikekommuunstring.
Teisel juhul on eesmärgiks avastada turvaauke mitte ainult kolmanda osapoole komponentides (sõltuvustes), vaid eelkõige uue toote koodis.
See põhjustab erinevusi vahendites ja lähenemisviisides. Minu arvates on rakenduses uute turvaaukude leidmise ülesanne palju huvitavam, kuna see ei taandu versioonide sõrmejälgede võtmisele, bännerite kogumisele, paroolide toomisele jõule jne.
Kvaliteetne rakenduste haavatavuste automaatne skannimine nõuab algoritme, mis võtavad arvesse rakenduse semantikat, eesmärki ja konkreetseid ohte.
Infrastruktuuri skanneri saab sageli asendada taimeriga, kuna . Asi on selles, et puhtalt statistiliselt võite pidada oma infrastruktuuri haavatavaks, kui te pole seda näiteks kuu aega värskendanud.
Töövahendid
Skaneerimist ja ka turvaanalüüsi saab teha musta kasti või valge kastina.
Must kast
Blackboxi skannimise korral peab tööriist suutma teenusega töötada samade liideste kaudu, mille kaudu kasutajad sellega töötavad.
Infrastruktuuri skannerid (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose jne) otsivad avatud võrguporte, koguvad "bännereid", tuvastavad installitud tarkvaraversioone ja otsivad oma teadmistebaasist teavet nende versioonide haavatavuste kohta. Samuti püüavad nad tuvastada konfiguratsioonivigu, nagu vaikeparoolid või avalik juurdepääs andmetele, nõrgad SSL-šifrid jne.
Veebirakenduste skannerid (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP jne) suudavad tuvastada ka teadaolevaid komponente ja nende versioone (nt CMS, raamistikud, JS teegid). Peamised roomamise etapid on roomamine ja udutamine.
Roomamise ajal kogub roomaja teavet olemasolevate rakendusliideste ja HTTP parameetrite kohta. Hägustamise ajal asendatakse kõik tuvastatud parameetrid muteeritud või genereeritud andmetega, et tekitada viga ja tuvastada haavatavus.
Sellised rakendusskannerid kuuluvad DAST ja IAST klassidesse – vastavalt Dynamic ja Interactive Application Security Testing.
Valge kast
Valge kasti skannimisel on erinevusi rohkem.
VM-i protsessi osana antakse skanneritele (Vulners, Insecurity Couch, Vuls, Tenable Nessus jne) sageli juurdepääs süsteemidele autentitud skannimise teel. Seega saab skanner installitud pakettide versioonid ja konfiguratsiooniparameetrid alla laadida otse süsteemist, ilma neid võrguteenuste bänneritelt ära arvamata.
Skaneerimine on täpsem ja täielikum.
Kui räägime rakenduste whitebox skaneerimisest (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs jne), siis tavaliselt räägime staatilisest koodianalüüsist ja vastavate SAST klassi tööriistade kasutamisest - Static Application Security Testing.
Probleemid
Skaneerimisel on palju probleeme! Pean enamikuga neist isiklikult tegelema nii hoone skaneerimise ja turvaliste arendusprotsesside teenuse osutamise raames kui ka turvaanalüüsitööde tegemisel.
Toon välja 3 peamist probleemide rühma, mida kinnitavad ka vestlused erinevate ettevõtete inseneride ja infoturbeteenuste juhtidega.
Veebirakenduste skannimise probleemid
- Rakendamise raskus. Skannerid tuleb kasutusele võtta, konfigureerida, iga rakenduse jaoks kohandada, eraldada skannimiseks testkeskkond ja rakendada CI / CD protsessis, et need oleksid tõhusad. Vastasel juhul on see kasutu ametlik protseduur, mis annab ainult valepositiivseid tulemusi
- Skaneerimise kestus. Skannerid teevad isegi 2019. aastal liideste dubleerimisel kehva tööd ja suudavad päevade jooksul skannida tuhat lehekülge, millest igaühel on 10 parameetrit, pidades neid erinevateks, kuigi nende eest vastutab sama kood. Samal ajal tuleb arendustsükli jooksul tootmisse kasutuselevõtu otsus teha kiiresti.
- Halvad soovitused. Skannerid annavad üsna üldisi soovitusi ja arendajal ei ole alati võimalik neist kiiresti aru saada, kuidas riskitaset vähendada ja mis kõige tähtsam, kas seda tuleb teha kohe või pole veel hirmutav.
- Hävitav mõju rakendusele. Skannerid saavad hõlpsasti sooritada rakendusele DoS-ründe, samuti võivad nad luua suure hulga olemeid või muuta olemasolevaid (näiteks luua blogisse kümneid tuhandeid kommentaare), mistõttu ei tohiks tootes mõtlematult skannimist käivitada.
- Haavatavuse tuvastamise kvaliteet on halb. Skannerid kasutavad tavaliselt fikseeritud massiivi kasulikke koormusi ja võivad kergesti kahe silma vahele jätta haavatavuse, mis ei sobi nende teadaoleva rakenduskäitumisega.
- Skänner ei saa rakenduse funktsioonidest aru. Skännerid ise ei tea, mis on “internetipank”, “makse”, “kommentaar”. Nende jaoks on ainult lingid ja parameetrid, nii et tohutu kiht võimalikke äriloogika haavatavusi jääb täielikult katmata, nad ei arva ära topelt mahakandmist, teiste inimeste andmeid ID järgi piilumist ega saldo ümardamise teel.
- Skänneri arusaamatus lehe semantikast. Skannerid ei saa lugeda KKK-d, ei tunne captchasid ära, nad ei arva ise, kuidas registreeruda ja seejärel uuesti sisse logida, et "logout" ei saa klõpsata ja kuidas parameetrite väärtuste muutmisel taotlusi allkirjastada. Selle tulemusena võib suurem osa rakendusest jääda üldse skannimata.
Lähtekoodi skannimise probleemid
- Valepositiivsed tulemused. Staatiline analüüs on keeruline ülesanne, mis hõlmab palju kompromisse. Täpsus tuleb sageli ohverdada ja isegi kallid ettevõtte skannerid tekitavad tohutul hulgal valepositiivseid tulemusi.
- Rakendamise raskus. Staatilise analüüsi täpsuse ja täielikkuse suurendamiseks on vaja täpsustada skaneerimisreegleid ning nende reeglite kirjutamine võib olla liiga aeganõudev. Mõnikord on lihtsam leida kõik koodis mingi veaga kohad ja need parandada, kui kirjutada reegel selliste juhtumite tuvastamiseks.
- Sõltuvustoetuse puudumine. Suured projektid sõltuvad suurest hulgast raamatukogudest ja raamistikest, mis laiendavad programmeerimiskeele võimalusi. Kui skanneri teadmistebaas ei sisalda teavet ohtlike kohtade ("vajub") kohta nendes raamistikes, muutub see pimealaks ja skanner lihtsalt ei saa isegi koodist aru.
- Skaneerimise kestus. Koodis haavatavuste leidmine on keeruline ülesanne ka algoritmide osas. Seetõttu võib protsess viibida ja nõuda märkimisväärseid arvutusressursse.
- Madal katvus. Vaatamata ressursside tarbimisele ja skannimise kestusele peavad SAST-i tööriistade arendajad siiski tegema kompromisse ja analüüsima mitte kõiki olekuid, milles programm võib olla.
- Reprodutseeritavuse leidmine. Haavatavuseni viivale konkreetsele liini- ja kõnepinule osutamine on suurepärane, kuid tegelikult ei anna skanner sageli piisavalt teavet välise haavatavuse kontrollimiseks. Viga võib ju olla ka surnud koodis, mis on ründajale kättesaamatu.
Infrastruktuuri skaneerimise probleemid
- Ebapiisav laoseis. Suurtes infrastruktuurides, eriti geograafiliselt eraldatud infrastruktuurides, on sageli kõige raskem aru saada, milliseid hoste skannida. Teisisõnu on skaneerimise ülesanne tihedalt seotud varahalduse ülesandega.
- Halb prioriseerimine. Võrguskannerid annavad sageli palju tulemusi, millel on puudused, mida praktikas ei kasutata, kuid formaalselt on nende riskitase kõrge. Tarbija saab teate, mida on raske tõlgendada, ja pole selge, mis vajab esmalt parandamist
- Halvad soovitused. Skänneri teadmistebaas sisaldab sageli ainult väga üldist teavet haavatavuse ja selle parandamise kohta, nii et administraatorid peavad end Google'iga relvastama. Veidi parem on olukord whitebox skanneritega, mis võivad anda parandamiseks konkreetse käsu
- Käsitsi valmistatud. Infrastruktuuridel võib olla palju sõlme, mis tähendab, et seal võib olla palju vigu, mille aruandeid tuleb iga iteratsiooni ajal käsitsi sõeluda ja analüüsida
- Halb katvus. Infrastruktuuri skaneerimise kvaliteet sõltub otseselt turvaaukude ja tarkvaraversioonide alase teadmistebaasi suurusest. kus, , isegi turuliidritel puudub põhjalik teadmistebaas ning tasuta lahenduste andmebaasides on palju infot, mida juhtidel pole
- Probleemid lappimisega. Kõige sagedamini on infrastruktuuri haavatavuste lappimine paketi värskendamine või konfiguratsioonifaili muutmine. Siin on suur probleem, et süsteem, eriti pärand, võib värskenduse tulemusel käituda ettearvamatult. Tegelikult peate läbi viima tootmises oleva aktiivse infrastruktuuri integratsioonitestid.
Läheneb
Kuidas see võimalik on?
Järgnevates osades käsitlen üksikasjalikumalt näiteid ja seda, kuidas paljude nende probleemidega toime tulla, kuid praegu toon välja peamised valdkonnad, kus saate töötada:
- Erinevate skannimisvahendite koondamine. Mitme skanneri õige kasutamisega on võimalik saavutada teadmusbaasi ja tuvastamise kvaliteedi märkimisväärne kasv. Võite leida veelgi rohkem turvaauke kui kõigi eraldi töötavate skannerite summa, samas saate riskitaset täpsemalt hinnata ja rohkem soovitusi anda
- SAST ja DAST integreerimine. Nende vahel teavet jagades on võimalik suurendada DAST-i katvust ja SAST-i täpsust. Allikast saad infot olemasolevate marsruutide kohta ning DAST-i abil saad kontrollida, kas haavatavus on väljastpoolt nähtav
- Masinõpe™. Aastal 2015 I (ja ) statistika kasutamise kohta skanneritele häkkeri intuitsiooni andmiseks ja nende kiirendamiseks. See on kindlasti toit automatiseeritud turvaanalüüsi arendamiseks tulevikus.
- IAST-i integreerimine automaattestide ja OpenAPI-ga. CI/CD-konveieri sees on võimalik luua skannimisprotsess, mis põhineb tööriistadel, mis töötavad HTTP-puhverserveridena, ja funktsionaalsetel testidel, mis töötavad HTTP kaudu. OpenAPI/Swaggeri testid ja lepingud annavad skannerile puuduoleva teabe andmevoogude kohta, võimaldavad rakendusi skaneerida erinevates olekutes
- Õige konfiguratsioon. Iga rakenduse ja infrastruktuuri jaoks peate looma sobiva skannimisprofiili, võttes arvesse liideste arvu ja olemust, kasutatavaid tehnoloogiaid
- Skanneri kohandamine. Sageli ei saa rakendust skannida ilma skannerit muutmata. Näiteks on maksevärav, kus iga päring tuleb allkirjastada. Lüüsiprotokolli konnektorit kirjutamata nokitsevad skannerid meeletult vale allkirjaga päringuid. Samuti on vaja kirjutada spetsiaalsed skannerid teatud tüüpi vigade jaoks, näiteks
- Riskijuhtimine. Erinevate skannerite kasutamine ja integreerimine väliste süsteemidega, nagu varahaldus ja ohuhaldus, võimaldavad riskitaseme hindamiseks kasutada mitut parameetrit, nii et juhtkond saab arenduse või infrastruktuuri praegusest turbeseisundist adekvaatse pildi.
Olge kursis ja häirigem haavatavuse skannimist!
Allikas: www.habr.com