El sistema de vulnerabilidades y exposiciones comunes ( CVE ) proporciona un método de referencia para vulnerabilidades y exposiciones de seguridad de la información conocidas públicamente. [1] El FFRDC de ciberseguridad nacional de los Estados Unidos , operado por The MITRE Corporation , mantiene el sistema, con financiación de la División de ciberseguridad nacional de los Estados Unidos del Departamento de Seguridad Nacional de los Estados Unidos . [2] El sistema se lanzó oficialmente al público en septiembre de 1999. [3]
El Protocolo de automatización de contenido de seguridad utiliza CVE, y los identificadores de CVE aparecen en el sistema de Mitre, así como en la Base de datos de vulnerabilidades nacional de EE. UU . [4]
La documentación de MITRE Corporation define los identificadores CVE (también llamados "nombres CVE", "números CVE", "ID CVE" y "CVE") como identificadores únicos y comunes para vulnerabilidades de seguridad de la información conocidas públicamente en paquetes de software publicados públicamente. Históricamente, los identificadores CVE tenían un estado de "candidato" ("CAN-") y luego podían ser promovidos a entradas ("CVE-"), pero esta práctica terminó en 2005 [5] [6] y todos los identificadores ahora se asignan como CVE. La asignación de un número CVE no es una garantía de que se convertirá en una entrada CVE oficial (por ejemplo, un CVE puede ser asignado incorrectamente a un problema que no es una vulnerabilidad de seguridad, o que duplica una entrada existente).
Los CVE son asignados por una Autoridad de Numeración de CVE (CNA). [7] Si bien algunos proveedores actuaron como CNA antes, el nombre y la designación no se crearon hasta el 1 de febrero de 2005. [8] Existen tres tipos principales de asignaciones de números CVE:
Al investigar una vulnerabilidad o una vulnerabilidad potencial, resulta útil obtener un número CVE lo antes posible. Es posible que los números CVE no aparezcan en las bases de datos CVE de MITRE o NVD durante algún tiempo (días, semanas, meses o posiblemente años) debido a problemas que están sujetos a embargo (el número CVE se ha asignado pero el problema no se ha hecho público) o en casos en los que MITRE no investiga ni redacta la entrada debido a problemas de recursos. El beneficio de la candidatura temprana a CVE es que toda la correspondencia futura puede hacer referencia al número CVE. La información sobre cómo obtener identificadores CVE para problemas con proyectos de código abierto está disponible en Red Hat [9] y GitHub . [10]
Los CVE se aplican a software que se ha publicado públicamente; esto puede incluir versiones beta y otras versiones previas al lanzamiento si se utilizan ampliamente. El software comercial se incluye en la categoría "publicado públicamente", pero el software personalizado que no se distribuye generalmente no recibe un CVE. Además, a los servicios (por ejemplo, un proveedor de correo electrónico basado en la Web) no se les asignan CVE por vulnerabilidades encontradas en el servicio (por ejemplo, una vulnerabilidad XSS) a menos que el problema exista en un producto de software subyacente que se distribuya públicamente.
La base de datos CVE contiene varios campos:
Se trata de una descripción textual estandarizada de los problemas. Una entrada común es:
** RESERVADO ** Este candidato ha sido reservado por una organización o individuo que lo utilizará para anunciar un nuevo problema de seguridad. Cuando se haya publicado el candidato, se proporcionarán los detalles del mismo.
Esto significa que Mitre ha reservado el número de entrada para un problema o que un CNA ha reservado el número. Por lo tanto, cuando un CNA solicita un bloque de números CVE por adelantado (por ejemplo, Red Hat actualmente solicita CVE en bloques de 500), el número CVE se marcará como reservado, aunque el CNA no asigne el CVE en sí durante algún tiempo. Hasta que se asigne el CVE, Mitre tenga conocimiento de él (es decir, hasta que pase el embargo y el problema se haga público) y Mitre haya investigado el problema y escrito una descripción del mismo, las entradas aparecerán como "** RESERVADO **".
Esta es la fecha en que se creó la entrada. Para los CVE asignados directamente por Mitre, esta es la fecha en que Mitre creó la entrada CVE. Para los CVE asignados por los CNA (por ejemplo, Microsoft, Oracle, HP, Red Hat), esta también es la fecha en que fue creada por Mitre, no por el CNA. Cuando un CNA solicita un bloque de números CVE por adelantado (por ejemplo, Red Hat actualmente solicita CVE en bloques de 500), la fecha de entrada en la que se asigna el CVE al CNA.
Los siguientes campos se utilizaban anteriormente en registros CVE, pero ya no se utilizan.
Para soportar los CVE ID más allá de CVE-YEAR-9999 (también conocido como el "problema CVE10k" [11] ), se realizó un cambio en la sintaxis de CVE en 2014 y entró en vigencia el 13 de enero de 2015. [12]
La nueva sintaxis CVE-ID tiene una longitud variable e incluye:
Prefijo CVE + Año + Dígitos arbitrarios
Los dígitos arbitrarios de longitud variable comenzarán con cuatro dígitos fijos y se ampliarán con dígitos arbitrarios solo cuando sea necesario en un año calendario; por ejemplo, CVE-AAAA-NNNN y, si es necesario, CVE-AAAA-NNNNN, CVE-AAAA-NNNNNN, etc. Esto también significa que no será necesario realizar cambios en los CVE-ID asignados previamente, que incluyen todos un mínimo de cuatro dígitos.
CVE intenta asignar un CVE por problema de seguridad; sin embargo, en muchos casos esto llevaría a una cantidad extremadamente grande de CVE (por ejemplo, donde se encuentran varias docenas de vulnerabilidades de secuencias de comandos entre sitios en una aplicación PHP debido a la falta de uso htmlspecialchars()o la creación insegura de archivos en /tmp). [13]
Para abordar este problema, las pautas (sujetas a cambios) cubren la división y fusión de problemas en números CVE distintos. Como pauta general, primero se deben considerar los problemas que se fusionarán, luego se deben dividir los problemas por tipo de vulnerabilidad (por ejemplo, desbordamiento de búfer vs. desbordamiento de pila ), luego por la versión de software afectada (por ejemplo, si un problema afecta a la versión 1.3.4 a 2.5.4 y el otro afecta a la 1.3.4 a 2.5.8, se dividirían) y luego por el informante del problema (por ejemplo, si Alice informa un problema y Bob informa otro problema, los problemas se dividirían en números CVE separados). [13]
Otro ejemplo es el de Alice, que informa sobre una vulnerabilidad de creación de archivo /tmp en la versión 1.2.3 y anteriores del navegador web ExampleSoft; además de este problema, /tmpse encuentran otros problemas de creación de archivos. En algunos casos, se puede considerar que hay dos informantes (y, por lo tanto, se pueden dividir en dos CVE independientes, o si Alice trabaja para ExampleSoft y un equipo interno de ExampleSoft encuentra el resto, se pueden fusionar en un único CVE). Por el contrario, los problemas se pueden fusionar, como si Bob encuentra 145 vulnerabilidades XSS en ExamplePlugin para ExampleFrameWork independientemente de las versiones afectadas, etc., se pueden fusionar en un único CVE. [13]
La base de datos CVE de Mitre se puede buscar en la Búsqueda de lista CVE, y la base de datos CVE de NVD se puede buscar en la Búsqueda de base de datos de vulnerabilidades CVE y CCE.
Los identificadores CVE están destinados a usarse con respecto a la identificación de vulnerabilidades:
Vulnerabilidades y exposiciones comunes (CVE) es un diccionario de nombres comunes (es decir, identificadores CVE) para vulnerabilidades de seguridad de la información conocidas públicamente. Los identificadores comunes de CVE facilitan el intercambio de datos entre bases de datos y herramientas de seguridad de red independientes, y proporcionan una base para evaluar la cobertura de las herramientas de seguridad de una organización. Si un informe de una de sus herramientas de seguridad incorpora identificadores CVE, puede acceder de forma rápida y precisa a la información de reparación en una o más bases de datos independientes compatibles con CVE para remediar el problema. [14]
Se recomienda a los usuarios a quienes se les haya asignado un identificador CVE para una vulnerabilidad que se aseguren de colocar el identificador en todos los informes de seguridad, páginas web, correos electrónicos, etc. relacionados.
Según la sección 7 de las Reglas de la CNA, un proveedor que recibe un informe sobre una vulnerabilidad de seguridad tiene total discreción al respecto. [15] Esto puede generar un conflicto de intereses, ya que un proveedor puede intentar dejar fallas sin parchear al negar una asignación de CVE en primer lugar, una decisión que Mitre no puede revertir. El proyecto "!CVE" (no CVE), anunciado en 2023, tiene como objetivo recopilar vulnerabilidades que sean negadas por los proveedores, siempre que un panel de expertos del proyecto las considere válidas. [16]
Se han otorgado identificadores CVE para problemas falsos y problemas sin consecuencias de seguridad. [17] En respuesta, varios proyectos de código abierto han solicitado convertirse en la Autoridad de Numeración CVE (CNA) de su propio proyecto. [18]
CVE está patrocinado por la División Nacional de Seguridad Cibernética del Departamento de Seguridad Nacional de los Estados Unidos.
Existen varias formas de realizar una solicitud según cuáles sean sus requisitos:
Los avisos de seguridad de GitHub se basan en la lista de vulnerabilidades y exposiciones comunes (CVE)