🥇Kwesbaarheidskandering en veilige ontwikkeling. Deel 1

As deel van hul professionele aktiwiteite moet ontwikkelaars, pentesters en sekuriteitspersoneel prosesse soos Vulnerability Management (VM), (Secure) SDLC hanteer.
Onder hierdie frases is verskeie stelle praktyke en gereedskap wat gebruik word wat vervleg is, hoewel hul gebruikers verskil.

Tegnologiese vooruitgang het nog nie die punt bereik waar een instrument 'n persoon kan vervang vir die ontleding van die sekuriteit van infrastruktuur en sagteware nie.
Dit is interessant om te verstaan hoekom dit so is, en watter probleme mens in die gesig staar.

prosesse

Die kwesbaarheidsbestuurproses is ontwerp om infrastruktuursekuriteit en pleisterbestuur deurlopend te monitor.
Die Secure SDLC-proses ("veilige ontwikkelingsiklus") is ontwerp om toepassingsekuriteit tydens ontwikkeling en bedryf te handhaaf.

'n Soortgelyke deel van hierdie prosesse is die kwesbaarheidsbeoordelingsproses - kwesbaarheidsbeoordeling, kwesbaarheidskandering.
Die belangrikste verskil tussen skandering binne VM en SDLC is dat die doel in die eerste geval is om bekende kwesbaarhede in derdeparty-sagteware of in 'n konfigurasie te vind. Byvoorbeeld, 'n verouderde weergawe van Windows of die verstek gemeenskapstring vir SNMP.
In die tweede geval is die doel om kwesbaarhede nie net in derdeparty-komponente (afhanklikhede) op te spoor nie, maar hoofsaaklik in die kode van die nuwe produk.

Dit gee aanleiding tot verskille in instrumente en benaderings. Na my mening is die taak om nuwe kwesbaarhede in 'n toepassing te vind baie interessanter, aangesien dit nie neerkom op weergawe-vingerafdrukke, banierversameling, wagwoord brute force, ens.
Geoutomatiseerde skandering van hoë gehalte van toepassingskwesbaarhede vereis algoritmes wat die semantiek van die toepassing, sy doel en spesifieke bedreigings in ag neem.

Die infrastruktuurskandeerder kan dikwels met 'n timer vervang word, soos die avleonov. Die punt is dat u suiwer statisties u infrastruktuur as kwesbaar kan beskou as u dit byvoorbeeld 'n maand lank nie opgedateer het nie.

Tools

Skandering, sowel as sekuriteitsontleding, kan as 'n swart boks of 'n wit boks uitgevoer word.

Black Box

Met swartboksskandering moet die instrument met die diens kan werk deur dieselfde koppelvlakke waardeur gebruikers daarmee werk.

Infrastruktuurskandeerders (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, ens.) soek oop netwerkpoorte, versamel "baniere", identifiseer geïnstalleerde sagtewareweergawes en soek hul kennisbasis vir inligting oor kwesbaarhede in hierdie weergawes. Hulle probeer ook om konfigurasiefoute op te spoor soos verstekwagwoorde of publieke toegang tot data, swak SSL-syfers, ens.

Webtoepassingskandeerders (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, ens.) kan ook bekende komponente en hul weergawes opspoor (bv. CMS, raamwerke, JS-biblioteke). Die belangrikste kruipstappe is kruip en fuzzing.
Tydens deurkruiping samel die deurkruiser inligting oor bestaande toepassingskoppelvlakke en HTTP-parameters in. Tydens fuzzing word alle bespeurde parameters vervang met gemuteerde of gegenereerde data om 'n fout uit te lok en 'n kwesbaarheid op te spoor.

Sulke toepassingskandeerders behoort aan die DAST- en IAST-klasse - onderskeidelik dinamiese en interaktiewe toepassingsekuriteitstoetsing.

White Box

Met witboksskandering is daar meer verskille.
As deel van die VM-proses word skandeerders (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, ens.) dikwels toegang tot stelsels gegee deur 'n geverifieerde skandering uit te voer. Die skandeerder kan dus geïnstalleerde pakketweergawes en konfigurasieparameters direk vanaf die stelsel aflaai sonder om dit van netwerkdiensbaniere te raai.
Die skandering is meer akkuraat en volledig.

As ons praat oor witboksskandering (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, ens.) van toepassings, dan praat ons gewoonlik van statiese kode-analise en die gebruik van die ooreenstemmende SAST-klasinstrumente - Static Application Security Testing.

probleme

Daar is baie probleme met skandering! Ek moet die meeste van hulle persoonlik hanteer as deel van die verskaffing van 'n diens vir die bou van skandering en veilige ontwikkelingsprosesse, sowel as wanneer ek sekuriteitsontledingswerk doen.

Ek sal 3 hoofgroepe probleme uitsonder, wat ook bevestig word deur gesprekke met ingenieurs en hoofde van inligtingsekuriteitsdienste in verskeie maatskappye.

Webtoepassingskanderingskwessies

Moeilikheid van implementering. Skandeerders moet ontplooi, gekonfigureer, aangepas word vir elke toepassing, 'n toetsomgewing vir skanderings toegeken word en in die CI/CD-proses geïmplementeer word om effektief te wees. Andersins sal dit 'n nuttelose formele prosedure wees, wat slegs vals positiewe uitreik
Skandering duur. Skandeerders, selfs in 2019, doen 'n swak werk om koppelvlakke te dedupliseer en kan 'n duisend bladsye met 10 parameters elk dae lank skandeer, terwyl hulle anders beskou word, hoewel dieselfde kode daarvoor verantwoordelik is. Terselfdertyd moet die besluit om binne die ontwikkelingsiklus na produksie te ontplooi vinnig geneem word.
Swak aanbevelings. Skandeerders gee redelik algemene aanbevelings, en dit is nie altyd moontlik vir 'n ontwikkelaar om vinnig van hulle te verstaan hoe om die vlak van risiko te verminder nie, en bowenal, of dit nou gedoen moet word, of dit is nog nie skrikwekkend nie
Destruktiewe impak op die toepassing. Skandeerders kan maklik 'n DoS-aanval op 'n toepassing uitvoer, en hulle kan ook 'n groot aantal entiteite skep of bestaandes verander (byvoorbeeld tienduisende opmerkings op 'n blog skep), so jy moet nie onnadenkend 'n skandering in 'n produk uitvoer nie.
Swak kwaliteit van kwesbaarheid opsporing. Skandeerders gebruik gewoonlik 'n vaste reeks loonvragte en kan maklik 'n kwesbaarheid mis wat nie by hul bekende toepassingsgedrag pas nie.
Die skandeerder verstaan nie die funksies van die toepassing nie. Skandeerders self weet nie wat 'n "internetbank", "betaling", "opmerking" is nie. Vir hulle is daar net skakels en parameters, so 'n groot laag moontlike besigheidslogika-kwesbaarhede bly heeltemal ontbloot, hulle sal nie raai om 'n dubbele afskrywing te maak, ander mense se data per ID te loer of die balans deur afronding op te wikkel nie.
Misverstand van bladsy semantiek deur die skandeerder. Skandeerders kan nie FAQ lees nie, kan nie captchas herken nie, hulle sal nie self raai hoe om te registreer en dan weer aan te meld nie, dat jy nie op "logout" kan klik nie, en hoe om versoeke te teken wanneer parameterwaardes verander word. As gevolg hiervan kan die meeste van die toepassing enigsins ongeskandeer bly.

Bronkodeskanderingskwessies

Vals positiewes. Statiese analise is 'n komplekse taak wat baie kompromieë behels. Dikwels moet jy akkuraatheid opoffer, en selfs duur ondernemingskandeerders gee 'n groot aantal vals positiewe uit.
Moeilikheid van implementering. Om die akkuraatheid en volledigheid van statiese analise te verhoog, is dit nodig om die skanderingsreëls te verfyn, en die skryf van hierdie reëls kan te tydrowend wees. Soms is dit makliker om al die plekke in die kode met 'n soort fout te vind en dit reg te stel as om 'n reël te skryf om sulke gevalle op te spoor.
Gebrek aan afhanklikheidsondersteuning. Groot projekte is afhanklik van 'n groot aantal biblioteke en raamwerke wat die vermoëns van die programmeertaal uitbrei. As daar geen inligting oor gevaarlike plekke ("sinks") in hierdie raamwerke in die kennisbasis van die skandeerder is nie, sal dit 'n blindekol word, en die skandeerder sal eenvoudig nie eers die kode verstaan nie.
Skandering duur. Om kwesbaarhede in kode te vind, is ook 'n moeilike taak in terme van algoritmes. Daarom kan die proses moontlik vertraag word en aansienlike rekenaarhulpbronne vereis.
Lae dekking. Ten spyte van hulpbronverbruik en skanderingsduur, moet SAST-nutsmiddelontwikkelaars steeds kompromieë wend en nie alle toestande waarin 'n program kan wees, ontleed nie.
Om reproduceerbaarheid te vind. Om na die spesifieke lyn en oproepstapel te wys wat tot 'n kwesbaarheid lei, is wonderlik, maar in werklikheid verskaf die skandeerder dikwels nie genoeg inligting om na 'n eksterne kwesbaarheid te kyk nie. Die fout kan immers ook in die dooie kode wees, wat vir die aanvaller onbereikbaar is.

Infrastruktuurskanderingskwessies

Onvoldoende voorraad. In groot infrastruktuur, veral geografies geskei, is dit dikwels die moeilikste ding om uit te vind watter gashere om te skandeer. Met ander woorde, die taak van skandering is nou verwant aan die taak van batebestuur
Slegte prioritisering. Netwerkskandeerders lewer dikwels baie resultate met foute wat nie in die praktyk ontginbaar is nie, maar formeel is hul risikovlak hoog. Die verbruiker ontvang 'n verslag wat moeilik is om te interpreteer, en dit is nie duidelik wat eers reggestel moet word nie
Swak aanbevelings. Die skandeerderkennisbasis bevat dikwels net baie algemene inligting oor die kwesbaarheid en hoe om dit reg te stel, so admins sal hulself met Google moet bewapen. Die situasie is effens beter met witboksskandeerders, wat 'n spesifieke opdrag kan gee om reg te stel
Handgemaak. Infrastruktuur kan baie nodusse hê, wat beteken dat daar potensieel baie foute is, waarvan verslae met die hand by elke iterasie ontleed en ontleed moet word
Slegte dekking. Die kwaliteit van infrastruktuurskandering hang direk af van die grootte van die kennisbasis oor kwesbaarhede en sagteware-weergawes. Waarin, dit blyk, selfs die markleiers het nie 'n omvattende kennisbasis nie, en daar is baie inligting in die databasisse van gratis oplossings wat die leiers nie het nie
Probleme met pleister. Meestal is die herstel van infrastruktuurkwesbaarhede die opdatering van 'n pakket of die verandering van 'n konfigurasielêer. Die groot probleem hier is dat die stelsel, veral die nalatenskap een, onvoorspelbaar kan optree as gevolg van 'n opdatering. Trouens, jy sal integrasietoetse op 'n lewendige infrastruktuur in produksie moet uitvoer.

Benaderings

Hoe om te wees?
Ek gaan in meer besonderhede oor voorbeelde en hoe om baie van hierdie probleme te hanteer in die volgende dele in, maar vir eers sal ek die hoofareas aandui waarin jy kan werk:

Samevoeging van verskeie skanderingsinstrumente. Met die korrekte gebruik van veelvuldige skandeerders kan 'n aansienlike toename in die kennisbasis en die kwaliteit van die opsporing bereik word. Jy kan selfs meer kwesbaarhede vind as die som van alle skandeerders wat individueel loop, terwyl jy die vlak van risiko meer akkuraat kan assesseer en meer aanbevelings kan maak
SAST en DAST integrasie. Dit is moontlik om DAST-dekking en SAST-akkuraatheid te verhoog deur inligting tussen hulle te deel. Van die bron af kan jy inligting oor bestaande roetes kry, en met die hulp van DAST kan jy kyk of die kwesbaarheid van buite sigbaar is
Masjienleer™. In 2015 het ek vertel (en ещё) oor die gebruik van statistieke om skandeerders 'n kuberkraker se intuïsie te gee en dit te bespoedig. Dit is beslis voedsel vir die ontwikkeling van outomatiese sekuriteitsanalise in die toekoms.
IAST-integrasie met outotoetse en OpenAPI. Binne die CI/CD-pyplyn is dit moontlik om 'n skanderingsproses te skep gebaseer op gereedskap wat as HTTP-gevolmagtigdes werk en funksionele toetse wat oor HTTP werk. OpenAPI/Swagger toetse en kontrakte sal die skandeerder die ontbrekende inligting oor datavloei gee, maak dit moontlik om die toepassing in verskeie state te skandeer
Korrekte konfigurasie. Vir elke toepassing en infrastruktuur moet u 'n geskikte skanderingsprofiel skep, met inagneming van die aantal en aard van koppelvlakke, die tegnologieë wat gebruik word
Skandeerder aanpassing. Dikwels kan 'n toepassing nie geskandeer word sonder om die skandeerder te verander nie. 'n Voorbeeld is 'n betaalpoort waar elke versoek onderteken moet word. Sonder om 'n koppelaar na die poortprotokol te skryf, sal skandeerders onnadenkend na versoeke met 'n verkeerde handtekening pik. Dit is ook nodig om gespesialiseerde skandeerders vir 'n spesifieke tipe foute te skryf, soos Onveilige direkte voorwerpverwysing
Risiko bestuur. Die gebruik van verskeie skandeerders en integrasie met eksterne stelsels soos Batebestuur en Bedreigingsbestuur sal dit moontlik maak om veelvuldige parameters te gebruik om die vlak van risiko te assesseer, sodat bestuur 'n voldoende beeld van die huidige sekuriteitstoestand van die ontwikkeling of infrastruktuur kan kry.

Bly ingeskakel en laat ons die kwesbaarheidskandering ontwrig!

Bron: will.com

Kwesbaarheidskandering en veilige ontwikkeling. Deel 1