Innehåll
- Bara fakta
- Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv
- Redogöra för påverkan?
- Dags att byta system?
Källa: BrianAJackson / iStockphoto
Hämtmat:
Det är dags att skaka upp hur vi funderar på att bedöma risken för komponenter med öppen källkod.
Att utveckla ett system för att utvärdera hur allvarligt programvaruutvecklingssamhället bör ta sårbarheter är en utmaning för att uttrycka det lätt. Koden är skriven av människor och kommer alltid att ha brister. Frågan är, om vi antar att ingenting någonsin kommer att vara perfekt, hur kan vi bäst kategorisera komponenterna enligt deras risk på ett sätt som gör att vi kan fortsätta arbeta produktivt?
Bara fakta
Även om det finns många olika tillvägagångssätt som man kan vidta för att hantera detta problem, var och en med sin giltiga motivering, verkar den vanligaste metoden baseras på en kvantitativ modell.
Å ena sidan kan man använda ett kvantitativt tillvägagångssätt för att bedöma svårighetsgraden av en sårbarhet eftersom den är mer objektiv och mätbar, enbart baserad på de faktorer som är relaterade till själva sårbarheten.
Den här metodiken tittar på vilken typ av skador som skulle kunna uppstå om sårbarheten utnyttjas, med tanke på hur ofta komponenten, biblioteket eller projektet används i hela programvaruindustrin, samt faktorer som vilken typ av åtkomst den kan ge en angripare till vrakförödelse bör de använda det för att bryta mot sitt mål. Faktorer som lätt potentiell utnyttjbarhet kan här spela en stor roll när det gäller att påverka poängen. (För mer om säkerhet, kolla in Cybersecurity: Hur nya framsteg ger nya hot - och vice versa.)
Om vi vill titta på makronivå tittar det kvantitativa perspektivet på hur en sårbarhet kan skada besättningen, med mindre fokus på de skador som kan komma att drabbas av de företag som faktiskt drabbats av attacken.
Den nationella sårbarhetsdatabasen (NVD), kanske den mest kända databasen med sårbarheter, tar denna strategi för både versioner 2 och 3 av deras Common Vulnerability Scoring System (CVSS). På sin sida som förklarar deras statistik för utvärdering av sårbarheter skriver de om sin metod som:
Dess kvantitativa modell säkerställer repeterbar noggrann mätning och gör det möjligt för användare att se de underliggande sårbarhetsegenskaperna som användes för att generera poängen. Således är CVSS väl lämpat som ett standardmätningssystem för industrier, organisationer och regeringar som behöver exakta och konsekventa sårbarhetseffekter.
Baserat på de kvantitativa faktorerna som spelas kan NVD då komma med en svårighetsgrad, båda med ett nummer på deras skala - 1 till 10, där 10 är de svåraste - liksom kategorier av LÅG, MEDIUM och HÖG .
Inga buggar, ingen stress - din steg-för-steg-guide för att skapa livsförändrad programvara utan att förstöra ditt liv
Du kan inte förbättra dina programmeringsfärdigheter när ingen bryr sig om mjukvarukvalitet.
Redogöra för påverkan?
NVD verkar emellertid anstränga sig för att hålla sig borta om vad vi kan beteckna som mer kvalitativt mått på en sårbarhet, baserat på hur påverkande en viss exploit har varit att orsaka skador. För att vara rättvisa har de inverkan i den mån de mäter påverkan av sårbarheten på systemet och ser på faktorerna för konfidentialitet, integritet och tillgänglighet. Dessa är alla viktiga element att titta på - som med den lättare mätbara åtkomstvektorn, åtkomstkomplexiteten och autentiseringen - men de känner inte upp till uppgiften att relatera verkliga effekter när en sårbarhet orsakar en organisations verkliga förluster.
Ta till exempel Equifax-överträdelsen som avslöjade personligt identifierbar information från cirka 145 miljoner människor, inklusive deras körkortlicenser, personnummer och andra bitar som kan användas av skrupelfria karaktärer för att genomföra massiva bedrägerier.
Det var sårbarheten (CVE-2017-5638) som upptäcktes i Apache Struts 2-projektet som Equifax använde i sin webbapp som gjorde det möjligt för angriparna att gå vid ytterdörren och så småningom göra det med sina armar full av saftig personlig information .
Medan NVD med rätta gav det en svårighetsgrad på 10 och HÖG, berodde deras beslut på deras kvantitativa bedömning av dess potentiella skada och påverkades inte av den omfattande skada som inträffade senare när Equifax-brottet blev offentligt.
Detta är inte en övervakning av NVD, utan en del av deras uttalade policy.
NVD tillhandahåller CVSS "baspoäng" som representerar de medfödda egenskaperna för varje sårbarhet. Vi tillhandahåller för närvarande inte "tidsmässiga poäng" (mätvärden som ändras över tid på grund av händelser som är externa för sårbarheten) eller "miljöpoäng" (poäng anpassade för att återspegla påverkan av sårbarheten på din organisation).
För beslutsfattare bör det kvantitativa mätsystemet betyda mindre eftersom det tittar på chansen att det kommer att sprida skada över hela branschen. Om du är CSO för en bank, borde du vara bekymrad över den kvalitativa inverkan som en exploit kan ha om den används för att göra av med dina kunders data, eller värre, deras pengar. (Läs mer om olika typer av sårbarheter i The 5 Scariest Threats In Tech.)
Dags att byta system?
Så skulle sårbarheten i Apache Strusts 2 som användes i Equifax-fallet få en högre rangordning mot bakgrund av hur omfattande skadorna visade sig vara, eller skulle göra att skiftet visade sig vara alltför subjektivt för ett system som NVD att fortsätta?
Vi beviljar att det skulle vara oerhört svårt att komma med de nödvändiga uppgifterna för att få fram en "miljöpoäng" eller "tidsmässig poäng" som beskrivs av NVD, vilket öppnar cheferna för det fria CVSS-teamet för oändlig kritik och massor av arbete för NVD och andra för att uppdatera sina databaser när ny information kommer ut.
Det finns naturligtvis frågan om hur en sådan poäng skulle sammanställas, eftersom mycket få organisationer sannolikt kommer att ge upp de nödvändiga uppgifterna om effekterna av ett överträdelse såvida de inte krävdes enligt en lag om offentliggörande. Vi har sett från fallet med Uber att företag är villiga att betala ut snabbt i hopp om att hålla informationen kring ett brott från att nå pressen så att de inte får ett offentligt motslag.
Det som är nödvändigt är kanske ett nytt system som kan inkludera de goda ansträngningarna från sårbarhetsdatabaserna och lägga till sin egen ytterligare poäng när information blir tillgänglig.
Varför initiera detta extra lager av poäng när det föregående verkar ha gjort sitt jobb tillräckligt bra under alla dessa år?
Ärligt talat handlar det om ansvar för organisationer att ta ansvar för sina applikationer. I en idealvärld skulle alla kolla poängen på komponenterna som de använder i sina produkter innan de läggs till i sin inventering, får varningar när nya sårbarheter upptäcks i projekt som tidigare trott vara säkra och implementera nödvändiga korrigeringar på egen hand .
Kanske om det fanns en lista som visade hur förödande vissa av dessa sårbarheter kan vara för en organisation, kan organisationer kännas mer press att inte fastna på riskfyllda komponenter. Åtminstone kan de vidta åtgärder för att ta en verklig inventering av vilka öppna källkodsbibliotek de redan har.
I följd av Equifax-fiaskot var det troligt att mer än en verkställande på C-nivå rusade för att se till att de inte hade den sårbara versionen av Struts i sina produkter. Det är olyckligt att det tog en incident av den här storleken att driva branschen att ta sin öppen källkodssäkerhet på allvar.
Förhoppningsvis kommer lektionen att sårbarheter i open source-komponenterna i dina applikationer kan få mycket verkliga konsekvenser i världen att påverka hur beslutsfattare prioriterar säkerhet, genom att välja rätt verktyg för att hålla sina produkter och kunders data säkra.