Almindelige sårbarheder og eksponeringer - Common Vulnerabilities and Exposures

Den fælles Svagheder og Engagementer ( CVE ) system giver en reference-metode til offentligt kendte oplysninger-sikkerhedsmæssige sårbarheder og eksponeringer. USA's National Cybersecurity FFRDC , der drives af The Mitre Corporation , vedligeholder systemet med finansiering fra US National Cyber ​​Security Division i det amerikanske Department of Homeland Security. Systemet blev officielt lanceret for offentligheden i september 1999.

Den Sikkerhed Indhold Automation protokollen bruger CVE, og CVE-id'er er noteret på Mitres system samt i USA National Vulnerability Database .

CVE -identifikatorer

MITER Corporation's dokumentation definerer CVE-identifikatorer (også kaldet "CVE-navne", "CVE-numre", "CVE-ID'er" og "CVE'er") som unikke, fælles identifikatorer for offentligt kendte informationssikkerhedssårbarheder i offentligt frigivne softwarepakker. Historisk set havde CVE-identifikatorer status som "kandidat" ("CAN-") og kunne derefter forfremmes til poster ("CVE-"), men denne praksis blev afsluttet i 2005, og alle identifikatorer er nu tildelt som CVE'er. Tildelingen af ​​et CVE -nummer er ikke en garanti for, at det bliver en officiel CVE -post (f.eks. Kan et CVE blive forkert tildelt et problem, der ikke er et sikkerhedsrisiko, eller som duplikerer en eksisterende post).

CVE'er tildeles af en CVE -nummereringsmyndighed (CNA). Mens nogle leverandører fungerede som en CNA før, blev navnet og betegnelsen først oprettet den 1. februar 2005. Der er tre primære typer CVE -nummeropgaver:

  1. De Mitre Corporation fungerer som Editor og primær CNA
  2. Forskellige CNA'er tildeler CVE -numre til deres egne produkter (f.eks. Microsoft, Oracle, HP, Red Hat osv.)
  3. En tredjepartskoordinator, f.eks. CERT Coordination Center, kan tildele CVE-numre for produkter, der ikke er omfattet af andre CNA'er

Når man undersøger en sårbarhed eller potentiel sårbarhed, hjælper det med at erhverve et CVE -nummer tidligt. CVE -numre vises muligvis ikke i MITER- eller NVD CVE -databaserne i nogen tid (dage, uger, måneder eller potentielt år) på grund af problemer, der er embargo (CVE -nummeret er blevet tildelt, men problemet er ikke blevet offentliggjort), eller i tilfælde, hvor posten ikke undersøges og skrives op af MITER på grund af ressourceproblemer. Fordelen ved tidlig CVE -kandidatur er, at al fremtidig korrespondance kan referere til CVE -nummeret. Oplysninger om at få CVE -id'er til problemer med open source -projekter er tilgængelige fra Red Hat .

CVE'er er til software, der er blevet offentliggjort offentligt; dette kan omfatte betas og andre versioner før udgivelse, hvis de er meget udbredt. Kommerciel software er inkluderet i kategorien "offentligt frigivet", men specialbygget software, der ikke distribueres, vil normalt ikke få en CVE. Yderligere tjenester (f.eks. En webbaseret e-mailudbyder) tildeles ikke CVE'er for sårbarheder, der findes i tjenesten (f.eks. En XSS-sårbarhed), medmindre problemet findes i et underliggende softwareprodukt, der er offentligt distribueret.

CVE -datafelter

CVE -databasen indeholder flere felter:

Beskrivelse

Dette er en standardiseret tekstbeskrivelse af problemerne. En fælles post 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.

Det betyder, at postnummeret er reserveret af Mitre til et problem, eller at en CNA har reserveret nummeret. Så i det tilfælde, hvor en CNA anmoder om en blok med CVE -numre på forhånd (f.eks. Red Hat i øjeblikket anmoder om CVE'er i blokke på 500), vil CVE -nummeret blive markeret som reserveret, selvom CVE selv muligvis ikke er tildelt af CNA for nogle tid. Indtil CVE er tildelt, bliver Mitre gjort opmærksom på det (dvs. embargoen passerer, og spørgsmålet offentliggøres), og Mitre har undersøgt problemet og skrevet en beskrivelse af det, poster vises som "** RESERVERET ** ".

Referencer

Dette er en liste over webadresser og andre oplysninger

Registrer oprettelsesdato

Dette er den dato, posten blev oprettet. For CVE'er, der er tildelt direkte af Mitre, er dette den dato, Mitre oprettede CVE -posten. For CVE'er tildelt af CNA'er (f.eks. Microsoft, Oracle, HP, Red Hat osv.) Er dette også den dato, der blev oprettet af Mitre, ikke af CNA. Det tilfælde, hvor en CNA på forhånd anmoder om en blok af CVE -numre (f.eks. Red Hat i øjeblikket anmoder om CVE'er i blokke på 500) den indgangsdato, som CVE er tildelt CNA.

Forældede felter

Følgende felter blev tidligere brugt i ældre CVE -poster, men bruges ikke længere.

  • Fase: Den fase, CVE er i (f.eks. CAN, CVE).
  • Afstemninger: Tidligere ville bestyrelsesmedlemmer stemme ja eller nej om, hvorvidt CAN skulle accepteres eller omdannes til en CVE.
  • Kommentarer: Kommentarer til spørgsmålet.
  • Foreslået: Da spørgsmålet først blev foreslået.

Ændringer i syntaks

For at understøtte CVE-ID'er ud over CVE-YEAR-9999 (aka CVE10k-problemet) blev der foretaget en ændring af CVE-syntaksen i 2014 og trådte i kraft den 13. januar 2015.

Den nye CVE-ID-syntaks er variabel længde og indeholder:

CVE -præfiks + år + vilkårlige cifre

BEMÆRK: De vilkårlige cifre med variabel længde begynder med fire faste cifre og udvides kun med vilkårlige cifre, når det er nødvendigt i et kalenderår, f.eks. CVE-ÅÅÅÅ-NNNN og om nødvendigt CVE-ÅÅÅÅ-NNNNN, CVE-ÅÅÅÅ-NNNNNN og snart. Dette betyder også, at der ikke er behov for ændringer af tidligere tildelte CVE-ID'er, som alle indeholder mindst fire cifre.

CVE SPLIT og MERGE

CVE forsøger at tildele et CVE pr. Sikkerhedsproblem, men i mange tilfælde ville dette føre til et ekstremt stort antal CVE'er (f.eks. Hvor flere dusin cross-site scripting-sårbarheder findes i en PHP-applikation på grund af manglende brug af htmlspecialchars()eller usikker oprettelse af filer i /tmp).

For at håndtere dette er der retningslinjer (med forbehold for ændringer), der dækker opdeling og sammenlægning af spørgsmål til forskellige CVE -numre. Som en generel retningslinje bør man først overveje, at emner skal flettes, derefter skal problemerne opdeles efter typen af ​​sårbarhed (f.eks. Bufferoverløb vs. stackoverløb ), derefter af den berørte softwareversion (f.eks. Hvis et problem påvirker version 1.3.4 til og med 2.5.4 og den anden påvirker 1.3.4 til 2.5.8 de ville være SPLIT) og derefter af problemets reporter (f.eks. Alice rapporterer et problem, og Bob rapporterer et andet problem, problemerne ville være SPLIT i separate CVE -numre).

Et andet eksempel er Alice rapporterer en /tmp -filoprettelse -sårbarhed i version 1.2.3 og tidligere versioner af eksempelSoft -webbrowseren, ud over dette problem findes der flere andre /tmpfiloprettelsesproblemer, i nogle tilfælde kan dette betragtes som to journalister (og dermed SPLIT i to separate CVE'er, eller hvis Alice arbejder for ExampleSoft, og et ExempelSoft -internt team finder resten, kan det blive MERGE'et i en enkelt CVE). Omvendt kan problemer flettes, f.eks. Hvis Bob finder 145 XSS -sårbarheder i ExamplePlugin for ExampleFrameWork uanset de berørte versioner og så videre kan de blive slået sammen til en enkelt CVE.

Søg CVE -identifikatorer

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

CVE brug

CVE -identifikatorer er beregnet til brug med hensyn til at identificere sårbarheder:

Fælles sårbarheder og eksponeringer (CVE) er en ordbog med almindelige navne (dvs. CVE -identifikatorer) for offentligt kendte informationssikkerhedssårbarheder. CVE's fælles identifikatorer gør det lettere at dele data på tværs af separate netværkssikkerhedsdatabaser og -værktøjer og giver et grundlag for evaluering af dækningen af ​​en organisations sikkerhedsværktøjer. Hvis en rapport fra et af dine sikkerhedsværktøjer indeholder CVE-identifikatorer, kan du derefter hurtigt og præcist få adgang til rettelsesoplysninger i en eller flere separate CVE-kompatible databaser for at afhjælpe problemet.

Brugere, der har fået tildelt et CVE -id for en sårbarhed, opfordres til at sikre, at de placerer identifikatoren i eventuelle relaterede sikkerhedsrapporter, websider, e -mails og så videre.

Problemer med CVE -opgaver

I henhold til afsnit 7.1 i CNA -reglerne har en leverandør, der har modtaget en rapport om et sikkerhedsrisiko, fuld skønsbeføjelse med hensyn til det. [1] Dette kan føre til en interessekonflikt, da en sælger kan forsøge at efterlade fejl upåvirket ved at nægte en CVE -opgave i første omgang - en beslutning, som Mitre ikke kan omvende.

Se også

Referencer

eksterne links