Para beneficio de la comunidad de ciberseguridad y los defensores de la red, y para ayudar a cada organización a gestionar mejor las vulnerabilidades y mantenerse al día con la actividad de amenazas, CISA mantiene la fuente autorizada de vulnerabilidades que han sido explotadas en la naturaleza: el catálogo de vulnerabilidades explotadas conocidas (KEV). CISA recomienda encarecidamente que todas las organizaciones revisen y monitoreen el catálogo KEV y prioricen la reparación de las vulnerabilidades enumeradas para reducir la probabilidad de que actores de amenazas conocidos las vulneren.
Todas las agencias de la rama ejecutiva civil federal (FCEB) deben reparar las vulnerabilidades en el catálogo KEV dentro de los plazos prescritos según la Directiva operativa vinculante (BOD) 22-01, Reducción del riesgo significativo de vulnerabilidades explotadas conocidas. Aunque no están sujetas a la norma BOD 22-01, todas las organizaciones, incluidas las de los gobiernos estatales, locales, tribales y territoriales (SLTT) y la industria privada, pueden fortalecer significativamente su postura de seguridad y resiliencia al priorizar también la remediación de las vulnerabilidades enumeradas en el catálogo KEV. CISA recomienda encarecidamente que todas las partes interesadas incluyan un requisito para abordar de inmediato las vulnerabilidades del catálogo KEV como parte de su plan de gestión de vulnerabilidades. Hacerlo generará resiliencia colectiva en toda la comunidad de ciberseguridad.
¿Cómo deberían las organizaciones utilizar el catálogo KEV?
El catálogo KEV envía un mensaje claro a todas las organizaciones para que prioricen los esfuerzos de remediación en el subconjunto de vulnerabilidades que están causando daño inmediato en función de la actividad del adversario. Las organizaciones deben utilizar el catálogo KEV como un insumo para su marco de priorización de gestión de vulnerabilidades. Los marcos de gestión de vulnerabilidades, como el modelo de categorización de vulnerabilidades específicas de las partes interesadas (SSVC), consideran el estado de explotación de una vulnerabilidad y el catálogo KEV sirve como repositorio autorizado de esa información. Las organizaciones también deben considerar el uso de herramientas automatizadas de administración de vulnerabilidades y parches que incorporen y marquen o prioricen automáticamente las vulnerabilidades de KEV.
Las siguientes secciones detallan los criterios detrás de cada uno de los tres umbrales para las actualizaciones del catálogo de KEV, que son:
La vulnerabilidad tiene un identificador de vulnerabilidades y exposiciones comunes (CVE) asignado.
Existe evidencia confiable de que la vulnerabilidad ha sido explotada activamente en la naturaleza.
Existe una acción de remediación clara para la vulnerabilidad, como una actualización proporcionada por el proveedor.
Criterio n.° 1: ID de CVE asignado
El primer criterio para agregar una vulnerabilidad al catálogo de KEV es la asignación de un ID de CVE. Un ID de CVE, también conocido como identificador de CVE, registro de CVE, nombre de CVE, número de CVE y CVE, es un identificador único y común para una vulnerabilidad de ciberseguridad conocida públicamente. (Consulte https://www.cve.org/ResourcesSupport/FAQs.)
El Programa CVE está patrocinado por CISA y dirigido por un centro de investigación y desarrollo sin fines de lucro financiado por el gobierno federal (FFRDC), que es operado por The MITRE Corporation. La misión del Programa CVE es identificar, definir y catalogar vulnerabilidades de ciberseguridad divulgadas públicamente. (Consulte https://www.cve.org/About/Overview.)
El proceso de obtención de un CVE ID comienza con el descubrimiento de una posible vulnerabilidad de ciberseguridad. Luego, una Autoridad de Numeración CVE (CNA) asigna un CVE ID a la información. (Consulte https://www.cve.org/About/Process#CVERecordLifecycle.) Una CNA es una organización autorizada para asignar y completar los CVE ID a las vulnerabilidades que afectan a los productos dentro de su alcance específico y acordado. Convertirse en CNA es voluntario. Un CNA puede ser un proveedor de software, un proyecto de código abierto, un centro de coordinación, un proveedor de servicios de recompensas por errores o un grupo de investigación. (Consulte https://www.cve.org/ProgramOrganization/CNAs).
Después de que el CNA crea el registro CVE, incluida una descripción y referencias, MITRE lo publica en el sitio web de CVE. (Consulte https://www.cve.org/About/Process#CVERecordLifecycle).
El sitio web de la lista CVE® de MITRE https://cve.mitre.org/cve y el sitio web de la base de datos nacional de vulnerabilidades (NVD) https://nvd.nist.gov/, mantenido por el Instituto Nacional de Estándares y Tecnología (NIST), proporcionan una lista actualizada de todos los CVE asignados. La NVD está sincronizada con CVE de modo que cualquier actualización de CVE aparece inmediatamente en la NVD. Complementa la información proporcionada por la lista CVE con una base de datos de referencias de listas de verificación de seguridad, fallas de software relacionadas con la seguridad, configuraciones incorrectas, nombres de productos, métricas de impacto y un motor de búsqueda. (Consulte https://nvd.nist.gov/general/FAQ-Sections/General-FAQs.)
Según https://www.cve.org/About/Process#CVERecordLifecycle, una entrada de CVE puede estar en uno de los tres estados siguientes:
Reservado: el estado inicial de un registro de CVE; cuando el ID de CVE asociado está reservado por un CNA. Si el registro de CVE se muestra como reservado, los visitantes/usuarios pueden enviar una solicitud de CVE a MITRE a través de https://cveform.mitre.org/ para solicitar que se publique el registro de CVE. En el formulario, seleccione «Tipo de solicitud» como «Otro» y «Tipo de comentario» como «Problema».
Publicado: cuando un CNA completa los datos asociados con un CVE
