Vanlige sårbarheter og eksponeringer - Common Vulnerabilities and Exposures

Den felles Sikkerhetsproblemer og Eksponeringer ( CVE ) system gir et referanse-metode for offentlig kjente informasjonssikkerhetsproblemer og eksponeringer. USAs National Cybersecurity FFRDC , som drives av The Mitre Corporation , vedlikeholder systemet, med finansiering fra US National Cyber ​​Security Division i US Department of Homeland Security. Systemet ble offisielt lansert for publikum i september 1999.

The Security Content Automation Protocol bruker CVE, og CVE-ID er notert på Mitre system så vel som i USA National Vulnerability Database .

CVE -identifikatorer

MITER Corporations dokumentasjon definerer CVE-identifikatorer (også kalt "CVE-navn", "CVE-numre", "CVE-IDer" og "CVE-er") som unike, vanlige identifikatorer for offentlig kjente informasjonssikkerhetsproblemer i offentliggjorte programvarepakker. Historisk sett hadde CVE-identifikatorer status som "kandidat" ("CAN-") og kunne deretter forfremmes til oppføringer ("CVE-"), men denne praksisen ble avsluttet i 2005 og alle identifikatorer er nå tilordnet som CVE-er. Tildelingen av et CVE -nummer er ikke en garanti for at det blir en offisiell CVE -oppføring (f.eks. Kan et CVE bli feil tilordnet et problem som ikke er et sikkerhetsproblem, eller som dupliserer en eksisterende oppføring).

CVE -er tildeles av en CVE -nummereringsmyndighet (CNA). Mens noen leverandører fungerte som CNA før, ble navnet og betegnelsen ikke opprettet før 1. februar 2005. Det er tre hovedtyper av CVE -nummeroppgaver:

  1. De Mitre Corporation fungerer som redaktør og Primær CNA
  2. Ulike CNA tildeler CVE -numre for sine egne produkter (f.eks. Microsoft, Oracle, HP, Red Hat, etc.)
  3. En tredjepartskoordinator som CERT Coordination Center kan tildele CVE-numre for produkter som ikke dekkes av andre CNA-er

Når du undersøker en sårbarhet eller potensiell sårbarhet, hjelper det å skaffe et CVE -nummer tidlig. CVE -numre kan ikke vises i MITER- eller NVD CVE -databasene på en stund (dager, uker, måneder eller potensielt år) på grunn av problemer som er embargo (CVE -nummeret er tildelt, men problemet har ikke blitt offentliggjort), eller i tilfeller der oppføringen ikke forskes og skrives opp av MITER på grunn av ressursspørsmål. Fordelen med tidlig CVE -kandidatur er at all fremtidig korrespondanse kan referere til CVE -nummeret. Informasjon om å få CVE -identifikatorer for problemer med åpen kildekode -prosjekter er tilgjengelig fra Red Hat .

CVE er for programvare som har blitt offentliggjort. Dette kan inkludere betas og andre forhåndsversjoner hvis de er mye brukt. Kommersiell programvare er inkludert i kategorien "offentlig utgitt", men spesialbygd programvare som ikke distribueres vil vanligvis ikke få CVE. I tillegg tildeles tjenester (f.eks. En nettbasert e-postleverandør) ikke CVE-er for sårbarheter som finnes i tjenesten (f.eks. Et XSS-sårbarhet) med mindre problemet eksisterer i et underliggende programvareprodukt som er offentlig distribuert.

CVE -datafelt

CVE -databasen inneholder flere felt:

Beskrivelse

Dette er en standardisert tekstbeskrivelse av problemet / problemene. En vanlig oppføring er: 

** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.

Dette betyr at oppføringsnummeret har blitt reservert av Mitre for et problem, eller at en CNA har reservert nummeret. Så i tilfelle der en CNA ber om en blokk med CVE -nummer på forhånd (f.eks. Red Hat for øyeblikket ber om CVE -er i blokker på 500), blir CVE -nummeret merket som reservert, selv om CVE selv kanskje ikke er tilordnet av CNA for noen tid. Inntil CVE er tildelt, blir Mitre gjort oppmerksom på det (dvs. embargoen passerer og problemet blir offentliggjort), og Mitre har undersøkt problemet og skrevet en beskrivelse av det, og oppføringer vises som "** RESERVED ** ".

Referanser

Dette er en liste over nettadresser og annen informasjon

Registrer opprettelsesdato

Dette er datoen oppføringen ble opprettet. For CVE -er som er tildelt direkte av Mitre, er dette datoen Mitre opprettet CVE -oppføringen. For CVE -er som er tilordnet av CNA (f.eks. Microsoft, Oracle, HP, Red Hat, etc.) er dette også datoen som ble opprettet av Mitre, ikke av CNA. Tilfellet der en CNA ber om en blokk med CVE -nummer på forhånd (f.eks. Red Hat for øyeblikket ber om CVE -er i blokker på 500) oppføringsdatoen som CVE er tilordnet CNA.

Utdaterte felt

Følgende felt ble tidligere brukt i eldre CVE -poster, men brukes ikke lenger.

  • Fase: Fasen CVE er i (f.eks. CAN, CVE).
  • Avstemninger: Tidligere ville styremedlemmer stemme ja eller nei om hvorvidt CAN skal aksepteres eller omdannes til en CVE.
  • Kommentarer: Kommentarer til saken.
  • Foreslått: Når problemet først ble foreslått.

Endringer i syntaks

For å støtte CVE-ID-er utover CVE-YEAR-9999 (aka CVE10k-problemet) ble det gjort en endring i CVE-syntaksen i 2014 og trådte i kraft 13. januar 2015.

Den nye CVE-ID-syntaksen er variabel lengde og inkluderer:

CVE -prefiks + år + vilkårlige sifre

MERK: Vilkårlige sifre med variabel lengde begynner med fire faste sifre og utvides med vilkårlige sifre bare når det er nødvendig i et kalenderår, for eksempel CVE-ÅÅÅÅ-NNNN og om nødvendig CVE-ÅÅÅÅ-NNNNN, CVE-ÅÅÅÅ-NNNNNN, og så videre. Dette betyr også at det ikke vil være behov for endringer i tidligere tildelte CVE-ID-er, som alle inneholder minst fire sifre.

CVE SPLIT og MERGE

CVE prøver å tilordne ett CVE per sikkerhetsproblem, men i mange tilfeller vil dette føre til et ekstremt stort antall CVE-er (f.eks. Der flere titalls sårbarheter over flere sider finnes i en PHP-applikasjon på grunn av mangel på bruk htmlspecialchars()eller usikker opprettelse av filer i /tmp).

For å håndtere dette er det retningslinjer (med forbehold om endringer) som dekker deling og sammenslåing av problemer til distinkte CVE -numre. Som en generell retningslinje bør man først vurdere problemene som skal slås sammen, deretter bør problemene deles etter typen sårbarhet (f.eks. Bufferoverløp vs. stackoverflyt ), deretter av programvareversjonen som er berørt (f.eks. Hvis ett problem påvirker versjon 1.3.4 til og med 2.5.4 og den andre påvirker 1.3.4 til og med 2.5.8 de ville være SPLIT) og deretter av reporteren av saken (f.eks. Alice rapporterer ett problem og Bob rapporterer et annet problem, problemene ville være SPLIT i separate CVE -numre).

Et annet eksempel er at Alice rapporterer a /tmp -filopprettingsproblemet i versjon 1.2.3 og tidligere eksempler på SoftSoft -nettleseren, i tillegg til dette problemet finnes flere andre /tmpfilopprettingsproblemer, i noen tilfeller kan dette betraktes som to journalister (og dermed SPLIT i to separate CVE -er, eller hvis Alice jobber for ExampleSoft og et interne eksempel på TeamSoft finner resten, kan det bli slått sammen til en enkelt CVE). Omvendt kan problemer slås sammen, f.eks. Hvis Bob finner 145 XSS -sårbarheter i ExamplePlugin for ExampleFrameWork uavhengig av hvilke versjoner som er berørt, og så videre kan de slås sammen til en enkelt CVE.

Søk i CVE -identifikatorer

Mitre CVE -databasen kan søkes i CVE List Search , og NVD CVE -databasen kan søkes i Search CVE og CCE Sårbarhetsdatabase .

CVE -bruk

CVE -identifikatorer er beregnet på bruk med hensyn til å identifisere sårbarheter:

Vanlige sårbarheter og eksponeringer (CVE) er en ordbok med vanlige navn (dvs. CVE -identifikatorer) for offentlig kjente informasjonssikkerhetsproblemer. CVEs vanlige identifikatorer gjør det lettere å dele data på tvers av separate nettverkssikkerhetsdatabaser og verktøy, og gir en grunnlinje for å evaluere dekningen av en organisasjons sikkerhetsverktøy. Hvis en rapport fra et av dine sikkerhetsverktøy inneholder CVE-identifikatorer, kan du raskt og nøyaktig få tilgang til fikseinformasjon i en eller flere separate CVE-kompatible databaser for å løse problemet.

Brukere som har blitt tildelt en CVE -identifikator for et sårbarhet, oppfordres til å sikre at de plasserer identifikatoren i eventuelle relaterte sikkerhetsrapporter, nettsider, e -postmeldinger og så videre.

Problemer med CVE -oppgaver

I henhold til avsnitt 7.1 i CNA -reglene har en leverandør som mottok en rapport om et sikkerhetsproblem, fullt skjønn i forhold til det. [1] Dette kan føre til interessekonflikter ettersom en leverandør kan prøve å la feil være upåaktet ved å nekte en CVE -oppgave i utgangspunktet - en avgjørelse som Mitre ikke kan reversere.

Se også

Referanser

Eksterne linker