Achtergrond
image

Van CVE tot CVSS: wegwijs in het woud van kwetsbaarheden

woensdag 5 augustus 2020, 15:40 door Redactie, 7 reacties

Vorig jaar werden er elke dag gemiddeld 47 nieuwe kwetsbaarheden in allerlei soorten software geregistreerd. Dit jaar staat de teller al op een gemiddelde van 52 lekken per dag. Om de continue stroom aan kwetsbaarheden bij te houden werd de Common Vulnerabilities and Exposures (CVE)-lijst bedacht.

Met alleen al in 2019 meer dan 17.000 unieke kwetsbaarheden is een registratiesysteem niet voldoende. Het moet ook duidelijk zijn wat de impact van een kwetsbaarheid is. Het ene lek is tenslotte niet het andere lek. Daarvoor werd het Common Vulnerability Scoring System (CVSS) in het leven geroepen. CVE en CVSS spelen een belangrijke rol in hoe bedrijven, beheerders en onderzoekers met kwetsbaarheden omgaan en in dit artikel gaan we hier dieper op in.

Common Vulnerabilities and Exposures

Al sinds mensen software schrijven worden er fouten gemaakt, die tot bugs en kwetsbaarheden kunnen leiden. Ontwikkelaars komen vervolgens met een beveiligingsupdate voor het betreffende lek. Voor 1999 lieten ontwikkelaars wel weten dat er een kwetsbaarheid was verholpen, maar deze lekken waren vaak niet van een identificeerbare code voorzien. Securitybedrijven en andere partijen die beveiligingslekken monitoren gaven deze kwetsbaarheden in hun eigen databases en tooling elk een eigen naam. Hierdoor was het onduidelijk of securityproducten het over hetzelfde probleem hadden en was er geen gestandaardiseerde basis om ze te vergelijken.

In 1999 lanceerde de MITRE Corporation daarop de Common Vulnerabilities and Exposures (CVE)-lijst. CVE voorziet elke kwetsbaarheid van een uniek nummer. Dit maakt het eenvoudiger om kwetsbaarheden te volgen, informatie uit te wisselen en beveiligingsproducten te beoordelen. Het CVE-nummer begint met de letters CVE, gevolgd door een jaartal en een getal van vijf cijfers. In eerste instantie waren ervoor dit getal vier cijfers gereserveerd. Hierdoor was het echter mogelijk om maximaal 9999 kwetsbaarheden in een jaar te registreren. Vanwege het toenemend aantal gevonden beveiligingslekken werd daarop in 2015 een nieuwe versie met vijf cijfers van kracht.

CVE-nummers worden uitgegeven door een CVE Numbering Authority (CNA). MITRE is de primaire CNA. Vervolgens zijn er CNA's die alleen voor hun eigen kwetsbaarheden CVE-nummers uitgeven. Het gaat om bedrijven als Adobe, Apple, Google en Microsoft. Op dit moment zijn er meer dan 120 CNA's actief. Het grootste deel daarvan betref bedrijven. Daarnaast zijn er verschillende "Coordination Centers" die CVE-nummers aanvragen voor kwetsbaarheden die niet door de andere CNA's worden gedekt.

CNA's kunnen een CVE-nummer vragen voor een actueel beveiligingslek, maar het is ook mogelijk om een reeks van CVE-nummers te reserveren en die pas op een later moment te gebruiken. Het allereerste CVE-nummer, CVE-1999-0001, was voor een beveiligingslek in BSD. Beveiligingsbedrijven en overheidsinstanties maken in hun rapporten vaak melding van kwetsbaarheden die aanvallers gebruiken. Bekende voorbeelden CVE-2010-2568 (Windows-lek gebruikt door Stuxnet), CVE-2012-0158 (Microsoft Office-lek gebruikt via e-mailbijlagen), CVE-2017-0144 (Windows-lek gebruikt door WannaCry) en CVE-2019-19781 (Citrix-lek). Onlangs publiceerde het Amerikaanse Cybersecurity and Infrastructure Security Agency (CISA) nog een Top 10 van meest aangevallen CVE-nummers van de afgelopen jaren.

Common Vulnerability Scoring System

CVE maakt het mogelijk om kwetsbaarheden te identificeren en te volgen, maar het zegt niets over hoe ernstig een beveiligingslek is. Een lek waardoor een lokale gebruiker een denial of service kan veroorzaken is veel minder ernstig dan een kwetsbaarheid waardoor een aanvaller op afstand en zonder interactie van de gebruiker systemen kan overnemen.

Om de impact van een kwetsbaarheid inzichtelijk te maken kwam het Amerikaanse National Infrastructure Advisory Council (NIAC) in 2004 met het Common Vulnerability Scoring System (CVSS). CVSS biedt een gestandaardiseerde manier om de impact van een kwetsbaarheid te berekenen. Sinds 2005 is het CVSS ondergebracht bij het Forum of Incident Response and Security Teams (FIRST).

Een CVSS-score bestaat uit een schaal van 1 tot en met 10, waarbij 10 de maximale score is. De score is uit verschillende onderdelen opgebouwd. Zo wordt gekeken wat de aanvalsvector is (lokaal, fysiek of netwerk), hoe lastig het is om misbruik van de kwetsbaarheid te maken, of er interactie van de gebruiker is vereist en of de aanvaller over bepaalde permissies moet beschikken om de aanval uit te voeren. Verder wordt er ook gekeken wat de gevolgen van de kwetsbaarheid zijn voor de beschikbaarheid, vertrouwelijkheid en integriteit van informatie of het systeem.

Dit leidt tot een "basisscore" die kan worden aangevuld met een tijdelijke score, bijvoorbeeld de beschikbaarheid van exploitcode, en een omgevingsscore, die specifiek voor de organisatie van een gebruiker is. Organisaties kunnen zo zien welke kwetsbaarheden de grootste prioriteit moeten krijgen. Beveiligingslekken met een basisscore van 10 komen geregeld in het nieuws. Desondanks gaat het hier niet om uitzonderingen. Dit jaar zijn er al ruim tweehonderd van dergelijke beveiligingslekken geregistreerd. Om de CVSS-score te berekenen biedt FIRST een aparte calculator.

Bug branding

Naast het gebruik van CVE-nummers en CVSS zijn er de afgelopen jaren ook tal van beveiligingsonderzoekers en securitybedrijven geweest die door hen gevonden kwetsbaarheden voorzagen van namen, logo's en aparte websites. Ernstige kwetsbaarheden kunnen de nodige media-aandacht genereren. Bekende voorbeelden van de afgelopen jaren zijn Heartbleed, POODLE, Row hammer, Stagefright, Dirty COW, EternalBlue, KRACK, Ghost, BlueBorne, Meltdown, Spectre, EFAIL, RIDL, ZombieLoad, BEAST, FREAK, BlueKeep, Kr00K, SigRed, BadUSB, ShellShock.

Image

Logo's van: Heartbleed, Meltdown, ShellShock, Ghost en EFAIL

Critici stellen dat het hypen van kwetsbaarheden, ook wel "bug branding" genoemd, afleidt van andere kwetsbaarheden die moeten worden gepatcht. Vanwege de continue aandacht voor nieuwe beveiligingslekken zouden gebruikers op den duur ook murw worden en de berichtgeving negeren. Voorstanders stellen juist dat een aparte naam voor meer bewustzijn bij gebruikers zorgt om het gevonden probleem snel te verhelpen. "Als je elke kwetsbaarheid van een logo voorziet zullen mensen ze negeren en je motieven wantrouwen. Maar het is net zoals met stormen. Er is een reden dat de ergste stormen een naam krijgen", aldus beveiligingsexpert Bruce Schneier.

Reacties (7)
Reageer met quote
05-08-2020, 15:54 door Anoniem
Vanwege de continue aandacht voor nieuwe beveiligingslekken zouden gebruikers op den duur ook murw worden en de berichtgeving negeren.
O, dus dat hebben ze toch zelf wel in de gaten? Dat is al mooi.
Misschien in die score dan meteen iets verwerken wat aangeeft hoe realisitisch het is dat een bepaald lek zal
worden gebruikt en wat dan de te verwachten schade is. Zodat we niet steeds opgezadeld worden met die lekken
die puur theoretisch zijn (en waar bepaalde instituten kennelijk hun reputatie en budget mee verdienen).

Voorstanders stellen juist dat een aparte naam voor meer bewustzijn bij gebruikers zorgt om het gevonden probleem snel te verhelpen. "Als je elke kwetsbaarheid van een logo voorziet zullen mensen ze negeren en je motieven wantrouwen. Maar het is net zoals met stormen. Er is een reden dat de ergste stormen een naam krijgen", aldus beveiligingsexpert Bruce Schneier.
Oh dat heeft ie niet begrepen dan. Alle stormen krijgen een naam, alleen de naam van de ergste stormen blijft hangen,
en in dat geval wordt die naam ook niet hergebruikt. De namen worden op alfabetische volgorde per jaar toegekend,
dus als je ineens een storm Katrina in het nieuws ziet zonder dat je de namen beginnend A t/m J al voorbij hebt zien
komen dan weet je dat die namen wel zijn toegekend maar dat ze niet in het nieuws gekomen zijn.
Reageer met quote
05-08-2020, 21:49 door Anoniem
Door Anoniem:
Er is een reden dat de ergste stormen een naam krijgen", aldus beveiligingsexpert Bruce Schneier.
Oh dat heeft ie niet begrepen dan. Alle stormen krijgen een naam, alleen de naam van de ergste stormen blijft hangen,
en in dat geval wordt die naam ook niet hergebruikt.
Orkanen krijgen een naam, en sinds vorig jaar krijgen bij ons stormen die tot code oranje of rood leiden voor windstoten een naam. Dat zijn niet alle stormen; dat zijn, precies zoals Bruce Schneier stelt, de ergste stormen.
Reageer met quote
06-08-2020, 08:17 door Anoniem
Door Anoniem:
Vanwege de continue aandacht voor nieuwe beveiligingslekken zouden gebruikers op den duur ook murw worden en de berichtgeving negeren.
O, dus dat hebben ze toch zelf wel in de gaten? Dat is al mooi.
Misschien in die score dan meteen iets verwerken wat aangeeft hoe realisitisch het is dat een bepaald lek zal
worden gebruikt en wat dan de te verwachten schade is. Zodat we niet steeds opgezadeld worden met die lekken
die puur theoretisch zijn (en waar bepaalde instituten kennelijk hun reputatie en budget mee verdienen).
Dat zit al in de CVSS berekening, in onderdelen als Attack Vector, Attack Complexity, Privileges Required en User Interaction. Hoe realistisch het is dat een lek daadwerkelijk benut gaat worden hangt af van je omgeving. Neem een lek in een management interface van een appliance; als dat ding netjes in een management VLAN/VRF hangt, met als enige toegang tot dat netwerk een specifieke management server, dan is het risico van benutten al een heel stuk kleiner dan wanneer het ding direct aan het internet hangt.
Reageer met quote
06-08-2020, 13:09 door Anoniem
Door Anoniem:
Door Anoniem:
Vanwege de continue aandacht voor nieuwe beveiligingslekken zouden gebruikers op den duur ook murw worden en de berichtgeving negeren.
O, dus dat hebben ze toch zelf wel in de gaten? Dat is al mooi.
Misschien in die score dan meteen iets verwerken wat aangeeft hoe realisitisch het is dat een bepaald lek zal
worden gebruikt en wat dan de te verwachten schade is. Zodat we niet steeds opgezadeld worden met die lekken
die puur theoretisch zijn (en waar bepaalde instituten kennelijk hun reputatie en budget mee verdienen).
Dat zit al in de CVSS berekening, in onderdelen als Attack Vector, Attack Complexity, Privileges Required en User Interaction. Hoe realistisch het is dat een lek daadwerkelijk benut gaat worden hangt af van je omgeving. Neem een lek in een management interface van een appliance; als dat ding netjes in een management VLAN/VRF hangt, met als enige toegang tot dat netwerk een specifieke management server, dan is het risico van benutten al een heel stuk kleiner dan wanneer het ding direct aan het internet hangt.
Daarom is het ook belangrijk om niet blind te varen op CVSS score, maar altijd een eigen interpretatie te doen van de kwetsbaarheid. Voor de ene organisatie kan een kwetsbaarheid gevaarlijker zijn dan de andere.
Reageer met quote
06-08-2020, 19:31 door Anoniem
Door Anoniem:
Misschien in die score dan meteen iets verwerken wat aangeeft hoe realisitisch het is dat een bepaald lek zal
worden gebruikt en wat dan de te verwachten schade is.
Joh wat een goed idee! Misschien kunnen we die kans zelfs berekenen aan de hand van bijvoorbeeld of er publieke exploitcode beschikbaar is, hoe complex het uit te buiten is, welke aanvalsvector er gebruikt wordt, en of er gebruikersinteractie benodigd is. Fantastisch zeg! Waarom heeft nooit iemand daar nog aan gedacht! /sarcasm

Die dingen zitten dus allemaal al in het CVSS-systeem. Misschien moet je je even stil houden over dingen waar je niks over weet.
Reageer met quote
06-08-2020, 21:23 door karma4
Er is nog zoveel software waar niet naar gekeken wordt of dat de fouten nergens gemeld kunnen worden.
Reageer met quote
17-11-2020, 23:02 door Anoniem
Daarbij is het misschien leuk om te vermelden dat dit alleen "westerse" vulnerabillity databases zijn: https://www.first.org/global/sigs/vrdx/vdb-catalog
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.

Zoeken
search