Inhoud
- Gewoon de feiten
- Geen bugs, geen stress - Uw stapsgewijze handleiding voor het creëren van levensveranderende software zonder uw leven te vernietigen
- Accounting voor impact?
- Tijd om het systeem te veranderen?
Bron: BrianAJackson / iStockphoto
Afhaal:
Het is tijd om dingen op een rijtje te zetten met hoe we denken over het beoordelen van risico's voor open-source componenten.
Het ontwikkelen van een systeem om te beoordelen hoe serieus de softwareontwikkelingsgemeenschap kwetsbaarheden moet nemen, is een uitdaging om het licht uit te drukken. Code is geschreven door mensen en zal altijd fouten bevatten. De vraag is dan, als we aannemen dat niets ooit perfect zal zijn, hoe kunnen we de componenten het beste indelen op basis van hun risico op een manier waardoor we productief kunnen blijven werken?
Gewoon de feiten
Hoewel er veel verschillende benaderingen zijn om dit probleem aan te pakken, elk met hun eigen geldige rechtvaardiging, lijkt de meest gebruikelijke methode op een kwantitatief model te zijn gebaseerd.
Enerzijds kan het gebruik van een kwantitatieve benadering voor het beoordelen van de ernst van een kwetsbaarheid nuttig zijn, omdat deze objectiever en meetbaar is, uitsluitend op basis van de factoren die verband houden met de kwetsbaarheid zelf.
Deze methode kijkt naar wat voor soort schade zou kunnen optreden als het beveiligingslek zou worden misbruikt, rekening houdend met hoe vaak het component, de bibliotheek of het project in de software-industrie wordt gebruikt, evenals factoren zoals welke toegang het een aanvaller zou kunnen geven schade aanrichten als ze het gebruiken om hun doelwit te breken. Factoren zoals gemakkelijke potentiële exploiteerbaarheid kunnen hier een grote rol spelen bij het beïnvloeden van de score. (Voor meer informatie over beveiliging, bekijk Cybersecurity: hoe nieuwe vooruitgang nieuwe bedreigingen met zich meebrengt - en vice versa.)
Als we op macroniveau willen kijken, kijkt het kwantitatieve perspectief hoe een kwetsbaarheid de kudde kan schaden, minder gericht op de schade die zou kunnen vallen op de bedrijven die daadwerkelijk door de aanval worden getroffen.
De National Vulnerability Database (NVD), misschien wel de meest bekende database met kwetsbaarheden, neemt deze aanpak voor beide versies 2 en 3, hun Common Vulnerability Scoring System (CVSS). Op hun pagina met uitleg over hun statistieken voor het evalueren van kwetsbaarheden, schrijven ze over hun methode die:
Het kwantitatieve model zorgt voor herhaalbare nauwkeurige metingen terwijl gebruikers de onderliggende kwetsbaarheidskenmerken kunnen zien die werden gebruikt om de scores te genereren. CVSS is dus zeer geschikt als standaard meetsysteem voor industrieën, organisaties en overheden die nauwkeurige en consistente impactscores voor kwetsbaarheid nodig hebben.
Op basis van de kwantitatieve factoren die spelen, kan de NVD vervolgens een ernstscore bepalen, beide met een nummer op hun schaal - 1 tot en met 10, waarbij 10 de ernstigste is - evenals categorieën LAAG, MIDDEN en HOOG .
Geen bugs, geen stress - Uw stapsgewijze handleiding voor het creëren van levensveranderende software zonder uw leven te vernietigen
U kunt uw programmeervaardigheden niet verbeteren als niemand om softwarekwaliteit geeft.
Accounting voor impact?
De NVD lijkt echter een poging te doen om weg te blijven van wat we een meer kwalitatieve maatstaf voor een kwetsbaarheid kunnen noemen, op basis van de impact die een bepaalde exploit heeft gehad bij het veroorzaken van schade. Om eerlijk te zijn, nemen ze impact op voor zover ze de impact van de kwetsbaarheid op het systeem meten, waarbij ze kijken naar de factoren vertrouwelijkheid, integriteit en beschikbaarheid. Dit zijn allemaal belangrijke elementen om naar te kijken - zoals met de gemakkelijker meetbare toegangsvector, toegangscomplexiteit en authenticatie - maar ze voldoen niet aan de taak om de reële impact te relateren wanneer een kwetsbaarheid een organisatie echte verliezen veroorzaakt.
Neem bijvoorbeeld de Equifax-inbreuk die de persoonlijk identificeerbare informatie van ongeveer 145 miljoen mensen blootlegde, inclusief hun rijbewijsgegevens, sofinummers en andere stukjes die door gewetenloze karakters kunnen worden gebruikt om massale fraudeoperaties uit te voeren.
Het was de kwetsbaarheid (CVE-2017-5638) die werd ontdekt in het Apache Struts 2-project dat Equifax in hun web-app gebruikte waardoor de aanvallers door de voordeur konden lopen en uiteindelijk met hun armen vol sappige persoonlijke info konden komen .
Hoewel de NVD haar terecht een ernstscore van 10 en HOOG gaf, was hun beslissing te wijten aan hun kwantitatieve beoordeling van de potentiële schade en werd deze niet beïnvloed door de uitgebreide schade die later plaatsvond toen de Equifax-inbreuk openbaar werd.
Dit is geen toezicht van de NVD, maar een onderdeel van hun beleid.
De NVD biedt CVSS "basisscores" die de aangeboren kenmerken van elke kwetsbaarheid vertegenwoordigen. We bieden momenteel geen "tijdelijke scores" (statistieken die in de loop van de tijd veranderen als gevolg van gebeurtenissen buiten de kwetsbaarheid) of "milieuscores" (aangepaste scores om de impact van de kwetsbaarheid op uw organisatie weer te geven).
Voor besluitvormers zou het kwantitatieve meetsysteem minder belangrijk moeten zijn, omdat het kijkt naar de kansen dat het schade in de industrie zal verspreiden. Als u de CSO van een bank bent, moet u zich zorgen maken over de kwalitatieve impact die een exploit kan hebben als het wordt gebruikt om te vergelijken met de gegevens van uw klant, of erger, hun geld. (Meer informatie over verschillende soorten kwetsbaarheden in The 5 Scariest Threats In Tech.)
Tijd om het systeem te veranderen?
Dus zou de kwetsbaarheid in Apache Strusts 2 die in de Equifax-zaak werd gebruikt, een hogere rangorde krijgen, gezien de omvang van de schade, of zou de verschuiving veel te subjectief blijken te zijn voor een systeem als de NVD om volhouden?
We geven toe dat het heel moeilijk zou zijn om met de nodige gegevens te komen om een "milieuscore" of "tijdelijke score" te geven, zoals beschreven door de NVD, waardoor de managers van het gratis CVSS-team eindeloze kritiek en veel werk krijgen voor de NVD en anderen voor het bijwerken van hun databases wanneer er nieuwe informatie uitkomt.
Er is natuurlijk de vraag over hoe een dergelijke score zou worden opgesteld, aangezien zeer weinig organisaties waarschijnlijk de nodige gegevens over de impact van een inbreuk zullen aanbieden, tenzij zij daartoe verplicht waren door een openbaarmakingswet. We hebben uit het geval van Uber gezien dat bedrijven bereid zijn snel uit te betalen in de hoop dat de informatie rond een inbreuk de pers niet bereikt, anders zullen ze geconfronteerd worden met een publieke reactie.
Wat misschien nodig is, is een nieuw systeem dat de goede inspanningen van de kwetsbaarheidsdatabases zou kunnen integreren en hun eigen aanvullende score zou kunnen toevoegen wanneer informatie beschikbaar komt.
Waarom deze extra scorelaag in gang zetten als de vorige zijn werk al die jaren goed genoeg lijkt te hebben gedaan?
Eerlijk gezegd komt het er op aan dat organisaties verantwoordelijkheid nemen voor hun applicaties. In een ideale wereld zou iedereen de scores van de componenten die ze in hun producten gebruiken controleren voordat ze aan hun inventaris worden toegevoegd, meldingen ontvangen wanneer nieuwe kwetsbaarheden worden ontdekt in projecten waarvan eerder werd gedacht dat ze veilig waren, en de nodige patches zelf implementeren .
Misschien als er een lijst is die laat zien hoe verwoestend sommige van deze kwetsbaarheden voor een organisatie kunnen zijn, dan kunnen organisaties meer druk voelen om niet verstrikt te raken in risicovolle componenten. Op zijn minst kunnen ze stappen ondernemen om een echte inventarisatie te maken van welke open-source bibliotheken ze al hebben.
In de nasleep van het Equifax-fiasco, was waarschijnlijk meer dan één C-level executive bezig om ervoor te zorgen dat ze niet de kwetsbare versie van Struts in hun producten hadden. Het is jammer dat er een incident van deze omvang nodig was om de industrie ertoe te bewegen hun open-sourcebeveiliging serieus te nemen.
Hopelijk heeft de les dat kwetsbaarheden in de open-sourcecomponenten van uw applicaties zeer reële gevolgen kunnen hebben, een impact op hoe besluitvormers prioriteit geven aan beveiliging, door de juiste tools te kiezen om hun producten en de gegevens van hun klanten veilig te houden.