Indhold
- Bare fakta
- Ingen fejl, ingen stress - Din trinvis vejledning til oprettelse af livsændrende software uden at ødelægge dit liv
- Regnskabsmæssigt for virkningen?
- Tid til at ændre systemet?
Kilde: BrianAJackson / iStockphoto
Tag væk:
Det er tid til at ryste op med, hvordan vi overvejer at vurdere risiko for open source-komponenter.
At udvikle et system til vurdering af hvor alvorligt softwareudviklingssamfundet skal tage sårbarheder er en udfordring for at sige det let. Kode er skrevet af mennesker og vil altid have mangler. Spørgsmålet er, hvis vi antager, at intet nogensinde vil være perfekt, hvordan skal vi bedst kategorisere komponenterne efter deres risiko på en måde, der giver os mulighed for at fortsætte med at arbejde produktivt?
Bare fakta
Selvom der er mange forskellige tilgange, som man kunne tage for at tackle dette problem, hver med deres egen gyldige begrundelse, ser den mest almindelige metode ud til at være baseret på en kvantitativ model.
På den ene side kan anvendelse af en kvantitativ tilgang til at bedømme sværhedsgraden af en sårbarhed være nyttig, idet den er mere objektiv og målbar, udelukkende baseret på de faktorer, der er relateret til selve sårbarheden.
Denne metodik ser på, hvilken slags skade der kan opstå, hvis sårbarheden udnyttes, i betragtning af hvor vidt brugt komponenten, biblioteket eller projektet bruges i hele softwarebranchen, samt faktorer som, hvilken type adgang det kunne give en angriber til ødelægge ødelæggelse, hvis de bruger det til at bryde deres mål. Faktorer som let potentiel udnyttelse kan her spille en stor rolle i at påvirke partituret. (For mere om sikkerhed, se Cybersikkerhed: Hvordan nye fremskridt bringer nye trusler - og vice versa.)
Hvis vi ønsker at se på et makroniveau, ser det kvantitative perspektiv på, hvordan en sårbarhed kan skade besætningen, med mindre fokus på den skade, der kan blive på de virksomheder, der rent faktisk er ramt af angrebet.
National Vulnerability Database (NVD), måske den mest kendte database over sårbarheder, tager denne tilgang til både versioner 2 og 3 af deres Common Vulnerability Scoring System (CVSS). På deres side, der forklarer deres målinger for evaluering af sårbarheder, skriver de om deres metode, som:
Dens kvantitative model sikrer gentagelig nøjagtig måling, mens brugerne gør det muligt for de underliggende sårbarhedsegenskaber, der blev brugt til at generere scoringerne. Således er CVSS velegnet som et standard målesystem for industrier, organisationer og regeringer, der har brug for nøjagtige og ensartede sårbarhedspåvirkningsresultater.
Baseret på de kvantitative faktorer, der spilles, kan NVD derefter komme med en sværhedsgrad, begge med et tal på deres skala - 1 til 10, hvor 10 er de mest alvorlige - såvel som kategorier af LAV, MEDIUM og HØJ .
Ingen fejl, ingen stress - Din trinvis vejledning til oprettelse af livsændrende software uden at ødelægge dit liv
Du kan ikke forbedre dine programmeringsevner, når ingen er interesseret i softwarekvalitet.
Regnskabsmæssigt for virkningen?
NVD ser imidlertid ud til at gøre en indsats for at holde sig fri for, hvad vi kan betegne som et mere kvalitativt mål for en sårbarhed, baseret på hvor påvirkelig en bestemt udnyttelse har været med at forårsage skader. For at være retfærdig indarbejder de indflydelse, for så vidt de måler påvirkningen af sårbarheden på systemet ved at se på faktorerne for fortrolighed, integritet og tilgængelighed. Dette er alle vigtige elementer at se på - ligesom med den lettere målbare adgangsvektor, adgangskompleksitet og autentificering - men de føler ikke op til opgaven med at relatere virkningen i den virkelige verden, når en sårbarhed forårsager en organisations reelle tab.
Tag for eksempel Equifax-overtrædelsen, der afslørede personligt identificerbare oplysninger fra omkring 145 millioner mennesker, inklusive deres kørekortoplysninger, personnummer og andre bits, der kunne bruges af skrupelløse karakterer til at udføre massive svigoperationer.
Det var sårbarheden (CVE-2017-5638), der blev opdaget i Apache Struts 2-projektet, som Equifax brugte i deres web-app, der gjorde det muligt for angriberen at gå i hoveddøren og til sidst gøre det ud med deres arme fulde af saftige personlige oplysninger .
Mens NVD med rette gav det en sværhedsgrad på 10 og HØJ, skyldtes deres beslutning deres kvantitative vurdering af dens potentielle skade og blev ikke påvirket af den omfattende skade, der opstod senere, da Equifax-overtrædelsen blev offentlig.
Dette er ikke et tilsyn af NVD, men en del af deres erklærede politik.
NVD leverer CVSS "basisscore", der repræsenterer de medfødte egenskaber ved hver sårbarhed. Vi leverer ikke i øjeblikket "tidsmæssige scoringer" (målinger, der ændrer sig over tid på grund af begivenheder, der er eksterne for sårbarheden) eller "miljømæssige scores" (scores tilpasset til at afspejle indvirkningen af sårbarheden på din organisation).
For beslutningstagere skal det kvantitative målesystem være mindre, da det ser på chancerne for, at det spreder skade over branchen. Hvis du er CSO for en bank, skal du være opmærksom på den kvalitative virkning, som en udnyttelse kan have, hvis den bruges til at udligne med din kundes data eller, værre, deres penge. (Lær mere om forskellige typer af sårbarheder i De 5 mest uhyggelige trusler inden for teknik.)
Tid til at ændre systemet?
Så bør sårbarheden i Apache Strusts 2, der blev brugt i Equifax-sagen, få en højere placering i lyset af hvor omfattende skaden viste sig at være, eller ville gøre skiftet vise sig at være alt for subjektivt til et system som NVD til holde ved med?
Vi giver, at det ville være meget vanskeligt at komme med de nødvendige data for at komme med en "miljømæssig score" eller "tidsmæssig score" som beskrevet af NVD, hvilket ville åbne lederne af det gratis CVSS-team for uendelig kritik og masser af arbejde for NVD og andre til opdatering af deres databaser, når nye oplysninger kommer ud.
Der er selvfølgelig spørgsmålet om, hvordan en sådan score ville blive udarbejdet, da meget få organisationer sandsynligvis vil tilbyde de nødvendige data om virkningen af et brud, medmindre de blev krævet i en oplysningslov. Vi har set fra Uber-sagen, at virksomheder er villige til at udbetale hurtigt i håb om at holde oplysningerne omkring et brud fra at nå pressen, så de ikke står over for et offentligt tilbageslag.
Det nødvendige er måske et nyt system, der kan inkorporere den gode indsats fra sårbarhedsdatabaserne og tilføje deres egen yderligere score, når information bliver tilgængelig.
Hvorfor indlede dette ekstra lag med score, når det foregående ser ud til at have gjort sit job godt nok i alle disse år?
Helt ærligt kommer det ned på ansvarlighed for organisationer at tage ansvar for deres applikationer. I en ideel verden ville alle tjekke partituret af komponenterne, de bruger i deres produkter, før de føjes dem til deres beholdning, modtage advarsler, når nye sårbarheder opdages i projekter, der tidligere blev antaget at være sikre, og implementere de nødvendige rettelser helt alene .
Måske hvis der var en liste, der viste, hvor ødelæggende nogle af disse sårbarheder kunne være for en organisation, kan organisationer måske føle et større pres for ikke at blive fanget med risikable komponenter. I det mindste kan de tage skridt til at tage en reel opgørelse over hvilke open source-biblioteker, de allerede har.
I efterspørgslen efter Equifax-fiaskoen var det sandsynligvis, at mere end en C-niveau-leder blandede sig for at sikre sig, at de ikke havde den sårbare version af Struts i deres produkter. Det er uheldigt, at det tog en hændelse i denne størrelsesorden at presse branchen til at tage deres open source-sikkerhed alvorligt.
Forhåbentlig vil lektionen om, at sårbarheder i open source-komponenterne i dine applikationer kan have meget virkelige konsekvenser, påvirke, hvordan beslutningstagere prioriterer sikkerhed ved at vælge de rigtige værktøjer til at holde deres produkter og kunders data sikre.