Estándar de especificación SCAP de vulnerabilidad de seguridad

En la investigación y gestión diaria de vulnerabilidades, generalmente se encuentra que diferentes plataformas de vulnerabilidad y diferentes equipos suelen tener diferentes definiciones de número y gravedad de vulnerabilidad.

Por ejemplo, los siguientes son 6 elementos comunes de vulnerabilidades:

Tomemos como ejemplo la vulnerabilidad Heartbleed:

Todos estos contenidos describen Heartbleed. Puede ver que diferentes plataformas tienen diferentes números y categorías. Los componentes, niveles y títulos afectados son todos diferentes. Por lo tanto, para los investigadores de seguridad o la gestión de vulnerabilidades, es inevitable que necesiten identificar si es lo mismo. vulnerabilidad, y luego debe determinar el nivel de vulnerabilidad y escribirlo usted mismo. Diferentes personas o equipos a menudo tienen contradicciones como las siguientes:

Esto se debe a diferentes conocimientos, comprensión de las vulnerabilidades y estándares, lo que conduce a estos problemas. Entonces, ¿existe un estándar unificado para abordar este problema? ¡Sí, SCAP!

SCAP

Hoy presentamos principalmente la versión SCAP1.0.

SCAP incluye Protocolo y Contenido. Protocolo significa que SCAP está compuesto por una serie de estándares públicos existentes. Estos estándares públicos se denominan Elementos SCAP. Protocolo especifica cómo estos elementos funcionan juntos. El contenido se refiere a los datos que se generan utilizando la descripción del Elemento y se aplican al trabajo de inspección real de acuerdo con el acuerdo del Protocolo.

Seis elementos de SCAP:

Puede que estés relativamente familiarizado con CVE y CVSS, así que los explicaré uno por uno:

CVE

CVE es relativamente fácil de entender. En términos simples, es una colección unificada y una numeración de vulnerabilidades. Por supuesto, esto es para vulnerabilidades de componentes comunes. Esta es la razón por la que a menudo se ve al personal de seguridad escribiendo en sus currículums cuántos CVE han sobrevivido. número, eso significa que la vulnerabilidad del componente común correspondiente al número fue descubierta por él en ese momento, lo cual es un símbolo de su capacidad de descubrimiento independiente de 0DAY; por supuesto, el CVE no refleja el impacto y la gravedad de la vulnerabilidad, por lo que Solo con el número CVE no veo nada, pero aún se puede aplicar una vulnerabilidad muy débil para un número CVE.

cvss

CVSS es un sistema de puntuación. El método de expresión básico es la puntuación directa de 5,0 como se muestra a la derecha, o algo similar a

CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N/RL:O/CR:L

En cuanto a la expresión de este vector, en cuanto a lo que aquí significa AV, AC, etc., podemos continuar leyendo a continuación para tener una idea aproximada.

La puntuación CVSS tiene tres grupos de indicadores. Generalmente, cuando observamos la gravedad de la vulnerabilidad en sí, nos fijamos principalmente en los indicadores básicos. Este indicador se calcula más a partir de algunos puntos de la vulnerabilidad en sí, y el grupo de indicadores de tiempo a veces también se calcula Por ejemplo, a medida que cambia el tiempo, si no había forma de explotar la vulnerabilidad en primer lugar, pero luego aparece, la explotación de la vulnerabilidad es completamente diferente, y el índice de peligro probablemente debería aumentar linealmente. Eternal Blue, cuando la vulnerabilidad estalló al principio, aunque iba acompañada de Exp, solo unas pocas personas saben cómo usarla, sin embargo, con la aparición de varios artículos sobre exploits en línea y complementos de MSF, personas de todo el mundo mundo están utilizando esta vulnerabilidad para atacar. Además, los indicadores ambientales se refieren principalmente al impacto de la vulnerabilidad en diferentes entornos. Puede variar.

Como mencioné hace un momento, ¿cuáles son los AV anteriores? De hecho, son estos elementos indicadores. Los detalles se pueden ver en la imagen a continuación. Están traducidos al chino en el PPT para facilitar la comprensión de todos. La H y la L aquí pueden representar alto y bajo. Para obtener más detalles, consulte la descripción del sitio web oficial https: //www.first .org/cvss/specification-document .

Volviendo al cálculo de la puntuación, ¿cómo calcular la puntuación? De hecho, existe una fórmula: tomemos como ejemplo el grupo de indicadores básicos.

Determine a qué situación pertenece cada indicador de la vulnerabilidad. Por ejemplo, los vectores de ataque incluyen red, red adyacente, local y físico. Se refieren a varias formas de lanzar ataques de vulnerabilidad. Las puntuaciones de los factores correspondientes utilizadas para el cálculo son 0,85, 0,62, 0,55 , 0,2. En términos generales, las vulnerabilidades que pueden atacarse directamente a través de la red son las más convenientes de explotar, por lo que tienen las puntuaciones más altas; lo mismo ocurre con varios otros indicadores.

Tomemos como ejemplo la vulnerabilidad "phpMyAdmin Reflected XSS Vulnerability (CVE-2013-1937)":

Luego aplica la fórmula para calcular:

ISCBase = 1 - [(1−ImpactConf) × (1−ImpactInteg) × (1−ImpactAvail)] = 1 - [(1−0.22) × (1−0.22) × (1−0)] = 0.3916

ISC =
Scope Unchanged 6.42 × ISCBase
Scope Changed 7.52 × [ISCBase−0.029] − 3.25 × [ISCBase−0.02]15
=7.52 × [0.3916−0.029] − 3.25 × [0.3916−0.02]15 = 2.72675084384

Exploitability
= 8.22 × AttackVector × AttackComplexity × PrivilegeRequired × UserInteraction
= 8.22 × 0.85 × 0.77 × 0.85 × 0.62 = 2.8352547300000004

If (ISC <= 0) 0 else,
Scope Unchanged Round up (Minimum [(Impact + Exploitability), 10])
Scope Changed Round up (Minimum [1.08 × (Impact + Exploitability), 10])
= Round up (Minimum [1.08 × (2.72675084384 + 2.8352547300000004), 10])
= Round up (Minimum [6.006966019747201, 10])
= 6.1

La puntuación base final para esta vulnerabilidad fue 6,1.

¿Crees que este cálculo es problemático? De hecho, no tiene por qué ser tan complicado, el sitio web oficial proporciona una calculadora en línea, simplemente selecciónala y se calculará automáticamente:

Esto es CVSS.

CPE

CPE es una enumeración de plataforma común. Al describir una vulnerabilidad, a menudo es necesario describir a qué componentes y versiones afecta la vulnerabilidad, luego se puede utilizar CPE.

CPE tiene tres formatos, a saber, WFN, URI y FS, y el formato correspondiente es

CPE:2.3:类型:厂商:产品:版本:更新版本:发行版本:界面语言:软件发行版本:目标软件:目标硬件:其他

El 2.3 anterior se refiere a la versión de CPE utilizada, porque CPE también tiene múltiples versiones. En la versión 2.2, los campos sw_edition, target_sw, target_hw y otros no existen. Para el método de representación específico, puede consultar el lado izquierdo de la figura de arriba Muestra.

Por supuesto, además de describir los componentes y las versiones correspondientes afectadas por la vulnerabilidad, CPE también se puede usar para comparar directamente si existe una vulnerabilidad. Para detectar la versión del componente para un determinado entorno, use CPE para describirlo y luego compararlo. con la vulnerabilidad. Al hacer coincidir la versión de CPE afectada, puede describir directamente si el entorno se ve afectado por esta vulnerabilidad. En este escenario, CPE utiliza el método de coincidencia correspondiente. Para obtener más detalles, consulte la figura anterior. Si es necesario Implementado en el código, también es muy simple. Generalmente, hay módulos listos para usar. Por ejemplo, Python tiene un paquete de terceros listo para usar, también llamado CPE, que contiene métodos de coincidencia y formato relacionados y se puede usar fácilmente.

CCE

Hablemos de CCE. De hecho, CCE es fácil de entender. Puede entenderse como el número CVE para la configuración básica. CVE es para vulnerabilidades de componentes comunes, mientras que CCE es para la configuración básica.

Por ejemplo, como se muestra en la imagen:

CCE-27868-9
Definición: La configuración de antigüedad máxima de la contraseña para la cuenta de servicio de Apache debe configurarse adecuadamente. Parámetro: número de días. Mecanismos técnicos: definidos por la política local o de grupo

CCE-27868-9 describe los requisitos para el tiempo de vencimiento máximo de la cuenta de servicio de Apache y requiere el uso de un valor apropiado.

OVAL

Sigamos hablando de OVAL, que es un lenguaje de descripción utilizado para definir detalles técnicos como elementos de inspección y vulnerabilidades. Parece difícil de entender esto. En términos sencillos, se puede entender que le indica cómo detectar la existencia de una determinada vulnerabilidad paso a paso en el entorno correspondiente. También tiene una biblioteca que se puede recuperar a través de dicho número. es 上图oval:org.mitre.oval:def:24241formato XML; tomemos Heart Bleeding como ejemplo:

Esto es parte de esto, que describe que bajo Ubuntu 12.04, si hay un paquete dpkg como libssl 1.0.0 en el sistema, y la versión es más pequeña que esa, significa que hay 0:1.0.1-4ubuntu5.12una vulnerabilidad Heartbleed.

OVAL utiliza un estándar unificado para describir los detalles de detección de una determinada vulnerabilidad, y la comunidad también puede contribuir con OVAL. De esta manera, el personal de seguridad y las herramientas de seguridad pueden detectar vulnerabilidades relacionadas basadas en OVAL.

XCCDF

Lo último de lo que tenemos que hablar es de XCCDF.

XCCDF se parece un poco a OVAL, pero XCCDF está diseñado para admitir el intercambio de información, la generación de documentos, el ajuste organizativo y contextual, las pruebas automáticas de coherencia y la puntuación de cumplimiento, y puede admitir la interacción con una variedad de tecnologías básicas de verificación de configuración. La tecnología de inspección recomendada y predeterminada es OVAL de MITRE. En aplicaciones SCAP reales, XCCDF y OVAL suelen aparecer en pares. Se puede entender que OVAL se puede utilizar como un subconjunto de XCCDF.

Además de OVAL, puedes ver CPE en el documento XCCDF. También es un archivo en formato XML.

Volviendo a mirar los seis elementos, tomé prestada una imagen de Internet para representarlos. De hecho, la relación y función entre ellos es aproximadamente la siguiente:

herramientas SCAP

Dicho esto, ¿existen herramientas relevantes que puedan ayudarnos a utilizar SCAP? Por ejemplo, ¿cómo detectar y generar resultados de inspección basados en XCCDF? Los más famosos incluyen OpenSCAP:

Esta es probablemente una breve introducción a SCAP. Para obtener más información, puede consultar los documentos del sitio web oficial y algunos casos de aplicación.

De hecho, la función principal de SCAP es unificar estándares. En este caso, estos estándares se pueden aplicar directamente para realizar investigaciones, aprendizaje, uso, detección, etc. de vulnerabilidades relacionadas, sin investigadores de seguridad ni herramientas de seguridad. En términos generales, habrá No hay diferencias debido a diferentes interpretaciones. Surgen problemas como diferentes descripciones y definiciones. Generalmente, los productos de seguridad bien fabricados, incluso si tienen su propio conjunto de estándares, son compatibles con algunos SCAP, entre los cuales CVE es el más utilizado. Por supuesto, si tiene una comprensión diferente de los estándares durante el uso de SCAP, aún puede generar algunas diferencias, por ejemplo, en el proceso de cálculo de CVSS, aunque existen explicaciones oficiales y explicaciones para la determinación de diferentes indicadores de vulnerabilidad. También es posible que diferentes personas tengan diferentes entendimientos de las vulnerabilidades, lo que conducirá a diferentes resultados establecidos, y los valores calculados finales también serán diferentes. Esto es inevitable, pero SCAP está tratando de proporcionar un estándar unificado tanto como sea posible.

Nota: Recién agregado en SCAP versión 1.2

CCSS Common Configuration Scoring System, similar a CVSS, excepto que CVSS es para vulnerabilidades y está asociado con CVE; CCSS es para configuración y está asociado con CCE OCIL Open Checklist Interactive Language, similar a XCDDF

Otras lecturas

Denominación de vulnerabilidades

Con respecto al tema de los nombres de vulnerabilidades, hemos diseñado previamente un conjunto de especificaciones de nombres, que no son parte de la especificación SCAP. El propósito general es comprender aproximadamente qué tipo de vulnerabilidad es al nombrar la vulnerabilidad. También puede consultar el siguiente:

gramática

El nombre de la vulnerabilidad en la biblioteca de vulnerabilidades incluye principalmente el nombre del componente que genera la vulnerabilidad (es decir, el componente afectado por la vulnerabilidad): la versión afectada por la vulnerabilidad, la ubicación donde ocurre la vulnerabilidad, el tipo de vulnerabilidad y opcional. vectores Las reglas de nomenclatura son las siguientes:

漏洞影响组件名称+漏洞影响版本+漏洞产生位置+(向量)+漏洞类型

Nombre del componente afectado por la vulnerabilidad: el nombre del componente afectado por la vulnerabilidad se refiere principalmente al nombre del componente específico que genera la vulnerabilidad. Los componentes incluyen varias aplicaciones web, un determinado complemento, un determinado sistema, un determinado módulo general, etc. todos los cuales pueden denominarse componentes.
Versión afectada por la vulnerabilidad: la versión afectada por la vulnerabilidad se refiere al número de versión correspondiente al componente afectado por la vulnerabilidad. El número de versión aquí puede ser una única versión (como V1.0) o un rango (como> V1.0 y <2.0). ), o La configuración es el valor mínimo (como >V1.0) o el valor máximo (como \<V2.0).
Ubicación de la vulnerabilidad: la ubicación de la vulnerabilidad se refiere al problema específico que causa la vulnerabilidad: la ubicación del archivo donde se encuentra el problema (como /admin/admin.php) o el nombre de la función general específica o el nombre de la clase (como la función _LoadBMP) o ambas combinaciones de personas.
Vector: Vector se refiere a un vector, que es opcional y se refiere al punto de entrada de la vulnerabilidad (por ejemplo, el vector de una vulnerabilidad de inyección SQL es el parámetro id).
Tipo de vulnerabilidad: El tipo de vulnerabilidad se refiere al tipo de vulnerabilidad general, es decir, el nombre de la clasificación de vulnerabilidad bajo la clasificación general correspondiente a la vulnerabilidad.

en principio

Inicialmente puede comprender la información básica de la vulnerabilidad a través del nombre de la vulnerabilidad.
Evite la duplicación de nombres de vulnerabilidades tanto como sea posible.
Evite nombres de vulnerabilidad largos y sin sentido

Ejemplo

El archivo local ThinkSAAS 2.0.1 thinksaas.php contiene una vulnerabilidad
Vulnerabilidad de denegación de servicio de la función ImLib BMP Image _LoadBMP
Vulnerabilidad de inyección SQL del parámetro appid del archivo UFIDA U8 system/Server/CmxGetLoginType.php

Clasificación de vulnerabilidad

Con respecto al tema de la calificación de vulnerabilidad, muchas personas están acostumbradas a usar el término "alto, medio, bajo" o 1-10 para describir el nivel de vulnerabilidad. También he diseñado un conjunto basado en el modelo de riesgo DREAD de Microsoft, que tampoco forma parte de SCAP También puede consultar lo siguiente: Vulnerabilidades totales El nivel de riesgo se divide en 10 niveles, 1-4 es riesgo bajo, 5-7 es riesgo medio y 8-10 es riesgo alto.

Fórmula de cálculo

危险=发生的概率×潜在损失

Definición del elemento de puntuación

Pérdida potencial: ¿Cuánto se perdería si se explotara la falla?
Reproducibilidad: ¿Qué tan difícil es reproducir el ataque?
Explotabilidad: ¿Qué tan difícil es lanzar un ataque?
Usuarios afectados: En porcentaje aproximado, ¿cuántos usuarios están afectados?
Descubribilidad: ¿Es fácil encontrar el defecto?