Som en del av sin professionella verksamhet måste utvecklare, pentestare och säkerhetsproffs hantera processer som Vulnerability Management (VM), (Secure) SDLC.
Under dessa fraser finns olika uppsättningar av metoder och verktyg som används som är sammanflätade, även om deras användare skiljer sig åt.
Den tekniska utvecklingen har ännu inte nått den punkt där ett verktyg kan ersätta en person för att analysera säkerheten för infrastruktur och mjukvara.
Det är intressant att förstå varför det är så, och vilka problem man har att möta.
Processerna
Sårbarhetshanteringsprocessen är utformad för att kontinuerligt övervaka infrastruktursäkerhet och patchhantering.
Secure SDLC-processen ("säker utvecklingscykel") är utformad för att upprätthålla applikationssäkerhet under utveckling och drift.
En liknande del av dessa processer är Vulnerability Assessment-processen – sårbarhetsbedömning, sårbarhetsskanning.
Huvudskillnaden mellan att skanna inom VM och SDLC är att i det första fallet är målet att upptäcka kända sårbarheter i tredjepartsprogramvara eller i en konfiguration. Till exempel en föråldrad version av Windows eller standardgemenskapssträngen för SNMP.
I det andra fallet är målet att upptäcka sårbarheter inte bara i tredjepartskomponenter (beroenden), utan främst i koden för den nya produkten.
Detta ger upphov till skillnader i verktyg och tillvägagångssätt. Enligt min mening är uppgiften att hitta nya sårbarheter i en applikation mycket mer intressant, eftersom det inte handlar om versionsfingeravtryck, bannerinsamling, lösenord brute force, etc.
Högkvalitativ automatisk genomsökning av applikationssårbarheter kräver algoritmer som tar hänsyn till applikationens semantik, dess syfte och specifika hot.
Infrastrukturskannern kan ofta ersättas med en timer, som . Poängen är att rent statistiskt kan du betrakta din infrastruktur som sårbar om du inte har uppdaterat den på till exempel en månad.
Verktyg
Skanning, såväl som säkerhetsanalys, kan utföras som en svart låda eller en vit låda.
FÄRDSKRIVARE
Med blackbox-skanning måste verktyget kunna arbeta med tjänsten genom samma gränssnitt som användarna arbetar med den.
Infrastrukturskannrar (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose, etc.) letar efter öppna nätverksportar, samlar in "banners", identifierar installerade programvaruversioner och söker i deras kunskapsbas efter information om sårbarheter i dessa versioner. De försöker också upptäcka konfigurationsfel som standardlösenord eller offentlig åtkomst till data, svaga SSL-chiffer etc.
Webbapplikationsskannrar (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, etc.) kan också upptäcka kända komponenter och deras versioner (t.ex. CMS, ramverk, JS-bibliotek). De huvudsakliga krypstegen är krypning och fuzzing.
Under genomsökningen samlar sökroboten in information om befintliga applikationsgränssnitt och HTTP-parametrar. Under fuzzing ersätts alla detekterade parametrar med muterade eller genererade data för att provocera fram ett fel och upptäcka en sårbarhet.
Sådana applikationsskannrar tillhör klasserna DAST och IAST - respektive Dynamic och Interactive Application Security Testing.
vit Box
Med whitebox-skanning finns det fler skillnader.
Som en del av VM-processen får skannrar (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, etc.) ofta tillgång till system genom att utföra en autentiserad skanning. Således kan skannern ladda ner installerade paketversioner och konfigurationsparametrar direkt från systemet, utan att gissa dem från nätverkstjänstbanner.
Skanningen är mer exakt och komplett.
Om vi pratar om whitebox-skanning (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, etc.) av applikationer, då talar vi vanligtvis om statisk kodanalys och användningen av motsvarande SAST-klassverktyg - Static Application Security Testing.
Problem
Det finns många problem med att skanna! Jag måste hantera de flesta personligen som en del av tillhandahållandet av en tjänst för att bygga skanning och säkra utvecklingsprocesser, samt när jag bedriver säkerhetsanalysarbete.
Jag kommer att peka ut 3 huvudgrupper av problem, som också bekräftas av samtal med ingenjörer och chefer för informationssäkerhetstjänster i olika företag.
Webbapplikationsskanningsproblem
- Svårighet att genomföra. Skannrar måste distribueras, konfigureras, anpassas för varje applikation, tilldelas en testmiljö för skanningar och implementeras i CI/CD-processen för att vara effektiva. Annars kommer det att vara ett värdelöst formellt förfarande som endast utfärdar falska positiva resultat
- Skanningens varaktighet. Skannrar, även under 2019, gör ett dåligt jobb med att deduplicera gränssnitt och kan skanna tusen sidor med 10 parametrar vardera i dagar, med tanke på att de är olika, även om samma kod är ansvarig för dem. Samtidigt måste beslutet att distribuera till produktion inom utvecklingscykeln fattas snabbt.
- Dåliga rekommendationer. Scanners ger ganska generella rekommendationer, och det är inte alltid möjligt för en utvecklare att snabbt förstå av dem hur man kan minska risknivån, och viktigast av allt, om det behöver göras just nu eller om det inte är skrämmande än
- Destruktiv påverkan på applikationen. Scanners kan enkelt utföra en DoS-attack på en applikation, och de kan också skapa ett stort antal enheter eller ändra befintliga (till exempel skapa tiotusentals kommentarer på en blogg), så du bör inte tanklöst köra en skanning i en produkt.
- Dålig kvalitet på sårbarhetsdetektering. Skanners använder vanligtvis en fast uppsättning av nyttolaster och kan lätt missa en sårbarhet som inte passar in i deras kända programbeteende.
- Skannern förstår inte applikationens funktioner. Scanner själva vet inte vad en "internetbank", "betalning", "kommentar" är. För dem finns det bara länkar och parametrar, så ett stort lager av möjliga affärslogiska sårbarheter förblir helt avslöjade, de kommer inte att gissa sig till att göra en dubbel avskrivning, titta på andras data efter ID eller avveckla balansen genom avrundning
- Skannerns missförstånd av sidsemantik. Skanners kan inte läsa FAQ, kan inte känna igen captchas, de kommer inte själva gissa hur man registrerar sig och sedan loggar in igen, att man inte kan klicka på "logga ut" och hur man signerar förfrågningar när man ändrar parametervärden. Som ett resultat kan det mesta av programmet förbli osannat överhuvudtaget.
Problem med källkodsskanning
- Falska positiva. Statisk analys är en komplex uppgift som innebär många kompromisser. Ofta måste du offra noggrannheten, och till och med dyra företagsskannrar ger ut ett stort antal falska positiva resultat.
- Svårighet att genomföra. För att öka noggrannheten och fullständigheten av statisk analys är det nödvändigt att förfina skanningsreglerna, och att skriva dessa regler kan vara för tidskrävande. Ibland är det lättare att hitta alla platser i koden med någon slags bugg och fixa dem än att skriva en regel för att upptäcka sådana fall.
- Brist på beroendestöd. Stora projekt är beroende av ett stort antal bibliotek och ramverk som utökar programmeringsspråkets möjligheter. Om det inte finns någon information om farliga platser ("sänkor") i dessa ramverk i skannerns kunskapsbas kommer detta att bli en blind fläck, och skannern kommer helt enkelt inte ens att förstå koden.
- Skanningens varaktighet. Att hitta sårbarheter i kod är en svår uppgift även när det gäller algoritmer. Därför kan processen mycket väl bli försenad och kräva betydande datorresurser.
- Låg täckning. Trots resursförbrukning och skanningstid måste utvecklare av SAST-verktyg fortfarande ta till kompromisser och analysera inte alla tillstånd som ett program kan vara i.
- Hitta reproducerbarhet. Att peka på den specifika linjen och samtalsstacken som leder till en sårbarhet är bra, men i själva verket ger skannern ofta inte tillräckligt med information för att leta efter en extern sårbarhet. När allt kommer omkring kan felet också ligga i den döda koden, som är oåtkomlig för angriparen.
Infrastrukturskanningsproblem
- Otillräckligt lager. I stora infrastrukturer, särskilt geografiskt åtskilda sådana, är det ofta det svåraste att ta reda på vilka värdar som ska skannas. Uppgiften att skanna är med andra ord nära relaterad till uppgiften att förvalta tillgångar
- Dålig prioritering. Nätverksskannrar ger ofta många resultat med brister som inte går att utnyttja i praktiken, men formellt är risknivån hög. Konsumenten får en anmälan som är svår att tolka, och det framgår inte vad som måste korrigeras först
- Dåliga rekommendationer. Skannerns kunskapsbas innehåller ofta bara mycket allmän information om sårbarheten och hur man åtgärdar den, så administratörer måste beväpna sig med Google. Situationen är något bättre med whitebox-skannrar, som kan utfärda ett specifikt kommando för att fixa
- Handgjorda. Infrastrukturer kan ha många noder, vilket innebär att det potentiellt finns många brister, rapporter som måste analyseras och analyseras manuellt vid varje iteration
- Dålig täckning. Kvaliteten på infrastrukturskanning beror direkt på storleken på kunskapsbasen om sårbarheter och programvaruversioner. Vart i, , även marknadsledarna har inte en heltäckande kunskapsbas, och det finns mycket information i databaserna med gratislösningar som ledarna inte har
- Problem med patchning. Oftast är att korrigera sårbarheter i infrastrukturen att uppdatera ett paket eller ändra en konfigurationsfil. Det stora problemet här är att systemet, särskilt det äldre, kan bete sig oförutsägbart till följd av en uppdatering. Faktum är att du måste utföra integrationstester på en levande infrastruktur i produktion.
Närmar sig
Hur kan det vara?
Jag kommer att gå in mer i detalj om exempel och hur man hanterar många av dessa problem i följande delar, men för tillfället kommer jag att ange huvudområdena där du kan arbeta:
- Aggregering av olika skanningsverktyg. Med korrekt användning av flera skannrar kan en betydande ökning av kunskapsbasen och kvaliteten på upptäckten uppnås. Du kan hitta ännu fler sårbarheter än summan av alla skannrar som körs individuellt, samtidigt som du mer exakt kan bedöma risknivån och ge fler rekommendationer
- Integrering av SAST och DAST. Det är möjligt att öka DAST-täckningen och SAST-noggrannheten genom att dela information mellan dem. Från källan kan du få information om befintliga rutter, och med hjälp av DAST kan du kontrollera om sårbarheten syns utifrån
- Machine Learning™. 2015 har jag (och ) om att använda statistik för att ge skannrar en hackers intuition och påskynda dem. Detta är definitivt mat för utvecklingen av automatiserad säkerhetsanalys i framtiden.
- IAST-integration med autotester och OpenAPI. Inom CI/CD-pipelinen är det möjligt att skapa en skanningsprocess baserad på verktyg som fungerar som HTTP-proxyer och funktionstester som fungerar över HTTP. OpenAPI/Swagger-tester och kontrakt kommer att ge skannern den saknade informationen om dataflöden, gör det möjligt att skanna applikationen i olika tillstånd
- Korrekt konfiguration. För varje applikation och infrastruktur måste du skapa en lämplig skanningsprofil, med hänsyn till antalet och arten av gränssnitt, de tekniker som används
- Anpassning av skannern. Ofta kan en applikation inte skannas utan att skannern ändras. Ett exempel är en betalningsgateway där varje begäran måste undertecknas. Utan att skriva en anslutning till gatewayprotokollet kommer skannrar tanklöst att peka på förfrågningar med en felaktig signatur. Det är också nödvändigt att skriva specialiserade skannrar för en specifik typ av brister, som t.ex
- Riskhantering. Användningen av olika skannrar och integration med externa system som Asset Management och Threat Management kommer att tillåta flera parametrar att användas för att bedöma risknivån, så att ledningen kan få en adekvat bild av det aktuella säkerhetsläget för utvecklingen eller infrastrukturen.
Håll ögonen öppna och låt oss störa sårbarhetsskanningen!
Källa: will.com