Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
El análisis de firmware identifica debilidades en los componentes de firmware. Estos resultados pueden ayudarle a comprender los posibles riesgos de seguridad, pero debe interpretarlos cuidadosamente y en el contexto adecuado.
En este artículo se explican los campos relacionados con la debilidad que puede ver en los resultados del análisis de firmware. Explica cómo estos campos se relacionan entre sí y cómo evaluarlos colectivamente para priorizar de forma eficaz el riesgo.
Nota:
La presencia de una debilidad o de una vulnerabilidad CVE en un análisis de firmware no significa necesariamente que un dispositivo sea vulnerable. El impacto real de una debilidad depende de cómo se use el componente afectado dentro del sistema.
Señales de debilidad en el análisis de firmware
El análisis de firmware puede mejorar los resultados con varias señales estándar del sector. Cada señal representa un aspecto diferente del riesgo y no debe interpretarse de forma aislada.
Vulnerabilidades y exposiciones comunes (CVE)
Los CVE son vulnerabilidades de seguridad conocidas que se divulgan públicamente. El análisis de firmware asocia CVEs con los componentes extraídos del firmware cuando se identifica una coincidencia. Un único componente de firmware puede estar asociado a varios CV, y un único CVE puede aparecer en varios dispositivos o componentes.
Los CV resaltan un problema, pero no solo indican el impacto o la vulnerabilidad del problema.
Para obtener más información sobre las CV y el programa CVE, consulte la documentación oficial sobre vulnerabilidades y exposiciones comunes que MANTIENE MITRE.
Puntuaciones y versiones de CVSS
El análisis de firmware puede mostrar datos comunes del sistema de puntuación de vulnerabilidades (CVSS) para un CVE.
Pueden aparecer varias versiones de CVSS para el mismo CVE:
- CVSS v2: sistema de puntuación heredado que se aplica a vulnerabilidades más antiguas.
- CVSS v3: estándar ampliamente adoptado con métricas mejoradas.
- CVSS v4: versión más reciente que presenta dimensiones adicionales.
Hay varias versiones de CVSS porque la puntuación de vulnerabilidades evolucionó con el tiempo. Ver varias versiones de un CVE no significa que haya varias vulnerabilidades distintas.
Las puntuaciones de CVSS describen la gravedad técnica, no la probabilidad real de explotación.
Para obtener más información sobre las diferencias de puntuación y versión de CVSS, consulte la documentación oficial del Sistema de puntuación de vulnerabilidades (CVSS) oficial que mantiene FIRST.
Vector CVSS
Además de una puntuación numérica, un resultado de CVSS incluye una cadena vectorial que describe los factores que contribuyen a la puntuación, como:
- Nivel de acceso requerido.
- Complejidad del ataque.
- Impacto en la confidencialidad, integridad y disponibilidad.
El vector proporciona más contexto, como las condiciones y los factores de impacto que contribuyen a la clasificación de gravedad de un CVE.
Para obtener una explicación completa de las cadenas de vectores de CVSS y los significados de métricas, consulte la especificación CVSS publicada por FIRST.
Para obtener ejemplos de cómo se publican las puntuaciones y vectores de CVSS para las CVE, consulte la Base de datos nacional de vulnerabilidades (NVD) del Instituto Nacional de Estándares y Tecnología (NIST).
Vulnerabilidades explotadas conocidas (KEV) de CISA
Algunos CVE podrían estar marcados como parte del catálogo de vulnerabilidades explotadas conocidas (KEV) de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA). Esta designación indica que se sabe que la vulnerabilidad se aprovecha activamente en escenarios reales.
Nota:
- El estado de KEV refleja la actividad de explotación observada, no si se ve afectado un dispositivo específico.
- El estado de KEV en el análisis de firmware es actualmente un valor estático. Refleja el estado de la base de datos CVE de análisis de firmware en el momento en que se realizó el examen. Este valor no se actualiza dinámicamente. Para ver el estado de KEV más actualizado, vuelva a escanear la imagen de firmware.
KEV es una señal fuerte de riesgo inmediato.
Para obtener instrucciones sobre el estado y la corrección de KEV autoritativos, consulte el Catálogo de vulnerabilidades explotadas conocidas de CISA.
EPSS
El análisis de firmware puede incluir datos del Sistema de puntuación de predicción de vulnerabilidades (EPSS), que calcula la probabilidad de que se aproveche una vulnerabilidad.
Pueden aparecer dos valores relacionados:
- Puntuación de EPSS: la probabilidad estimada de explotación en función de las tendencias observadas en el ecosistema de vulnerabilidades.
- Percentil EPSS: cómo se compara la puntuación con respecto a otras vulnerabilidades.
Estos valores proporcionan contexto de riesgo comparativo, pero no garantizan la explotación.
Para filtrar por EPSS en el portal de Azure, especifique la puntuación de EPSS en un formato decimal. Por ejemplo, para una puntuación de EPSS de >50%, filtre por >0.5.
Las clasificaciones de percentil suelen ser más útiles de forma operativa, ya que muestran cómo un CVE clasifica en relación con el ecosistema de vulnerabilidades más amplio.
Nota:
El valor de EPSS es actualmente estático. Refleja el estado de la base de datos CVE de análisis de firmware en el momento en que se realizó el examen. Este valor no se actualiza dinámicamente. Para ver el estado de EPSS más reciente, vuelva a escanear la imagen de firmware.
EPSS proporciona una señal de probabilidad de futuro, no una garantía de explotación.
Para obtener más información sobre cómo se calculan las puntuaciones y percentiles de EPSS, consulte la documentación del sistema de puntuación de predicción de vulnerabilidades que mantiene FIRST.
CWE
Common Weakness Enumeration (CWE) representa la clase de debilidad subyacente (por ejemplo, desbordamiento del búfer o validación de entrada incorrecta) que provocó una vulnerabilidad, en lugar de una instancia de vulnerabilidad específica.
Los identificadores CWE proporcionan más contexto al describir por qué existe una vulnerabilidad, no solo donde se produce.
Los identificadores CWE son informativos y deben usarse para comprender las causas principales, en lugar de para la priorización.
Nota:
Los datos de CWE reflejan clasificaciones de debilidad estandarizadas definidas por el proyecto de enumeración de debilidad común de MITRE. Los identificadores CWE son informativos y no indican la vulnerabilidad de seguridad ni el impacto en una imagen de firmware o dispositivo específica por sí mismos.
Para obtener más información sobre las definiciones y clasificaciones de CWE, consulte la documentación oficial de MITRE CWE.
Madurez de exploits
La madurez del exploit describe el estado actual de disponibilidad de exploits para una vulnerabilidad. Las categorías pueden incluir etiquetas como:
- No comprobado
- Prueba de concepto
- Vulnerabilidad de seguridad funcional
- Explotación armada
Cuando hay información sobre la madurez del exploit, normalmente se encuentra junto a la puntuación CVSS v4. Se describe en la especificación CVSS que FIRST mantiene.
Uso de datos sobre debilidades de manera conjunta
Cada señal de debilidad representa una perspectiva diferente:
- CVE: Cuál es la vulnerabilidad.
- CVSS: gravedad técnica e impacto.
- KEV: evidencia de explotación activa.
- EPSS: probabilidad de explotación a corto plazo.
- Madurez del exploit: Disponibilidad de técnicas de explotación.
- CWE: categoría de debilidad subyacente.
En lugar de confiar en un único campo, la evaluación de estas señales proporciona una comprensión más completa del riesgo potencial.
Orden de evaluación recomendado para la priorización
La priorización efectiva requiere más que la puntuación de gravedad. El siguiente modelo estructurado muestra cómo puede evaluar holísticamente los datos de debilidad. Este enfoque es una guía, no un conjunto de reglas prescriptivo.
Confirmar el estado de explotación (KEV):
- Trate las debilidades enumeradas en KEV como prioridad más alta.
- No degrade elementos KEV únicamente en función de la puntuación de CVSS.
Debe evaluarse la explotación confirmada antes de cualquier métrica de puntuación.
Evaluación de la madurez de vulnerabilidades de seguridad:
- Eleve la prioridad de las debilidades con vulnerabilidades funcionales o tergiversadas.
- Combine la madurez del exploit con las características de la exposición.
La disponibilidad de exploits aumenta el riesgo real.
Evaluación de la probabilidad de explotación (EPSS):
- Use EPSS para diferenciar entre vulnerabilidades con gravedad similar.
- Los percentiles suelen ser más útiles para actuar que las puntuaciones brutas.
- Combine EPSS con KEV y aproveche la madurez.
EPSS agrega contexto de probabilidad a las decisiones de priorización.
Nota:
Para filtrar por EPSS en el portal de Azure, especifique la puntuación de EPSS en un formato decimal. Por ejemplo, para una puntuación de EPSS de
>50%, filtre por>0.5.Revise el vector de ataque y la exposición. Desde el vector CVSS, tenga en cuenta lo siguiente:
- Vulnerabilidades accesibles a la red frente al acceso local o físico.
- Requisitos de autenticación e interacción del usuario.
- Si el componente o el servicio afectados están expuestos en el despliegue.
Una vulnerabilidad puede aparecer grave, pero, si no es accesible en la práctica, presenta un riesgo reducido.
Evaluar la gravedad del impacto técnico (CVSS). Use CVSS para comprender el impacto si la explotación se realiza correctamente (no la probabilidad):
- Gravedad alta o crítica: priorice cuándo la exposición o probabilidad es moderada o superior.
- Gravedad media: priorice en función de las señales de explotación y la exposición.
- Gravedad baja: Asignar menor prioridad, salvo que exista explotación activa o una exposición elevada.
Cuando la probabilidad de dos vulnerabilidades es similar, primero solucione las vulnerabilidades de mayor impacto.
Evaluar el impacto empresarial. Determinar si un recurso es crítico refleja el contexto organizativo e incluye:
- Si el sistema es producción o infraestructura principal.
- Posible impacto operativo, de seguridad o cumplimiento.
El impacto empresarial influye en la urgencia, pero no cambia la mecánica de vulnerabilidades.
Tenga en cuenta la disponibilidad de correcciones. La viabilidad de la corrección afecta al planeamiento de la ejecución. Evaluar:
- Disponibilidad de parche o actualización de firmware.
- Complejidad de la actualización.
- Mitigaciones disponibles.
La disponibilidad de correcciones debe determinar la programación, pero no invalidar los indicios de explotación.
Consideraciones importantes
Interprete siempre los datos de debilidad junto con:
Rol y exposición del dispositivo.
Configuración del sistema.
Uso de firmware dentro de la plataforma.
Nota:
El análisis de firmware identifica posibles riesgos en función del contenido de firmware extraído. No determina si una vulnerabilidad es accesible, aprovechable o afecta a una implementación específica.
Para obtener más información sobre cómo el análisis de firmware extrae y presenta datos de componentes, consulte Interpretación de rutas de extractor desde la vista SBOM en el análisis de firmware.