Enhver sårbarhedsrapport, du modtager, er fuld af identifikatorer som CVE-2023-44487. De er ikke alvorlighedsvurderinger, ikke scorer og ikke en konstatering af, at du er i fare — de er katalognumre, og at vide hvad de betyder og ikke betyder gør rapporterne langt lettere at læse.
Hvad identifikatoren egentlig er
CVE står for Common Vulnerabilities and Exposures. En CVE-identifikator er et entydigt referencenummer på ét bestemt hul i ét bestemt produkt, og den findes for at løse et koordineringsproblem frem for et teknisk.
Før den fandtes, hed den samme sårbarhed noget forskelligt i hver leverandørs advarsel og hver scanners database, og ingen kunne afgøre, om to rapporter beskrev ét problem eller to. En fælles identifikator betyder, at din scanner, din styresystemsleverandør, en nyhedsartikel og en myndighedsadvarsel alle kan henvise entydigt til det samme.
Formatet er enkelt: CVE, året den blev tildelt, og et løbenummer — CVE-2023-44487. Årstallet er, hvornår identifikatoren blev reserveret, ikke nødvendigvis hvornår hullet blev fundet eller offentliggjort, så en CVE med sidste års nummer kan være splinterny for dig.
Numre uddeles af CVE Numbering Authorities under CVE-programmet, som MITRE driver på vegne af den amerikanske stat: organisationer, der er bemyndiget til at tildele identifikatorer inden for deres eget område. Mange store softwareleverandører er deres egen myndighed, og derfor kan en leverandør offentliggøre en advarsel og en identifikator samtidig. Der er kommet regionale kataloger til ved siden af — ENISA driver nu EU's sårbarhedsdatabase, som henviser til de samme CVE-identifikatorer.
CVSS: scoren, og hvad den måler
En CVE-identifikator bærer ingen alvorlighed. Den kommer fra CVSS — Common Vulnerability Scoring System — der giver et tal fra 0 til 10, som regel præsenteret i bånd: lav, middel, høj, kritisk.
Scoren bygges af egenskaber ved selve hullet: om det kan udnyttes over netværket eller kræver lokal adgang, hvor kompliceret angrebet er, om angriberen skal bruge adgangsoplysninger eller en bruger, der klikker på noget, og hvad de får ud af det — muligheden for at læse data, ændre dem eller tage systemet ned.
To ting ved CVSS er værd at få ind under huden, for de forklarer det meste af forvirringen:
Det er en alvorlighedsscore, ikke en risikoscore. Den beskriver, hvor slemt det ville være abstrakt betragtet, uden nogen viden om jeres miljø. En 9,8 i en komponent, I har eksponeret mod det offentlige internet, og en 9,8 i en komponent på en isoleret maskine er det samme tal og to meget forskellige problemer.
Den score, du får vist, ændrer sig ikke, når verden gør. CVSS definerer valgfri Threat-målepunkter — Exploit Maturity i version 4.0, Temporal-målepunkter før den — som er tænkt til at flytte sig, når der dukker udnyttelseskode op. Næsten ingen offentliggør dem: det, advarsler og scannere bærer, er Base-scoren, tildelt én gang ved offentliggørelsen. Den stiger ikke, når der dukker udnyttelseskode op, og den falder ikke, når det viser sig, at hullet kræver betingelser, ingen kører. I praksis er om nogen udnytter en sårbarhed ikke noget, tallet foran dig udtrykker — og derfor er en høj CVSS-score ikke nok til at afgøre, hvad der skal rettes først.
De tre spørgsmål, tallene ikke kan svare på
Kører jeg overhovedet den ramte version? Advarsler angiver versionsintervaller, og at få det rigtigt er sværere, end det ser ud — især med Linux-distributioner, som ofte lægger en rettelse på en ældre version uden at ændre nummeret. En pakke, der meldes som en gammel version, kan udmærket være lappet.
Kan den sårbare kode overhovedet nås i min brug? Mange huller gælder kun, når en bestemt funktion eller opsætning er slået til. At være til stede er ikke det samme som at være eksponeret, hvilket er hele forudsætningen bag VEX-dokumenter.
Er der nogen, der udnytter den? Det er det mest brugbare spørgsmål, når man skal beslutte, hvad man gør i eftermiddag — og det lever uden for både CVE'en og dens CVSS-score.
Hvad "ingen CVE" ikke betyder
Værd at slutte på, for det er en almindelig fejllæsning. En sårbarhed uden CVE-identifikator er ikke dermed ufarlig. Masser af rigtige huller bliver rettet i stilhed i en udgivelse, uden at der nogensinde bliver oprettet en advarsel, og nogle økosystemer — særligt den lange hale af plugins og små biblioteker — er dækket langt dårligere end almindelig serversoftware.
En ren CVE-rapport betyder, at ingen offentliggjorte, katalogiserede sårbarheder matchede det, du kører. Det er reelt nyttig information. Det er ikke det samme som ingen sårbarheder.
Hvad er en CVE?
CVE står for Common Vulnerabilities and Exposures, og en CVE-identifikator er et entydigt referencenummer på ét bestemt sikkerhedshul i ét bestemt produkt — for eksempel CVE-2023-44487. Den findes for at løse et koordineringsproblem: før den hed den samme sårbarhed noget forskelligt i hver leverandøradvarsel og scannerdatabase. Selve identifikatoren bærer ingen alvorlighed og er ikke en konstatering af, at du er i fare; det er et katalognummer, der lader alle henvise entydigt til det samme hul.
Hvad er forskellen på CVE og CVSS?
En CVE er identifikatoren for et bestemt hul; CVSS er det scoresystem, der vurderer, hvor alvorligt det ville være, fra 0 til 10. Scoren bygges af egenskaber ved selve hullet — om det kan udnyttes over netværket, hvor kompliceret angrebet er, om der kræves adgangsoplysninger, og hvad angriberen får ud af det. Det er en alvorlighedsscore frem for en risikoscore, for den ved ingenting om jeres miljø.
Hvem tildeler CVE-numre?
CVE-identifikatorer tildeles af CVE Numbering Authorities — organisationer, der er bemyndiget til at udstede numre inden for et afgrænset område, under CVE-programmet, som MITRE driver på vegne af den amerikanske stat. Mange store softwareleverandører er deres egen myndighed, og derfor kan en leverandør offentliggøre en advarsel og dens identifikator i samme øjeblik. Mindre projekter går i stedet gennem en generel myndighed, og årstallet i identifikatoren er, hvornår nummeret blev reserveret — ikke nødvendigvis hvornår hullet blev fundet.
Hvis en scanning ikke finder nogen CVE'er, er min software så sikker?
Det betyder, at ingen offentliggjorte, katalogiserede sårbarheder matchede det, du kører, hvilket er nyttigt, men ikke det samme som ingen at have. Rigtige huller bliver jævnligt rettet i stilhed i en udgivelse, uden at der nogensinde oprettes en advarsel, og dækningen varierer mellem økosystemer — den lange hale af plugins og små biblioteker er dokumenteret langt dårligere end almindelig serversoftware. En ren rapport er dokumentation, ikke en garanti.
Hvor VulnControl passer ind
VulnControl finder ud af, hvilken software dit website reelt kører, og matcher hver version mod et natligt opdateret spejl af den amerikanske nationale sårbarhedsdatabase (NVD), med markering af alt, der står i CISAs katalog over udnyttede huller. Matchningen sker på den formelle produktidentifikator inde i hver post frem for på ord i beskrivelsen, hvilket er forskellen på en brugbar og en ubrugelig rapport. Kan en version ikke fastslås, siger den det i stedet for at melde dig ren.