Skip to main content

Mejorar la seguridad del código a la nube con el Common Configuration Scoring System

feature datacenters black

14 de diciembre de 2023

0 minutos de lectura

La puntuación de gravedad propietaria suele ser una carga para los equipos de AppSec. Con cada nuevo proveedor, debes evaluar su marco de gravedad personalizado y trabajar para traducir los riesgos evaluados entre herramientas. Para eliminar esta carga y ofrecer a nuestros clientes una evaluación clara de la seguridad de las configuraciones en todo el SDLC, Snyk avanzará hacia la estandarización de su conjunto de reglas de seguridad del código a la nube según el Common Configuration Scoring System (CCSS).

Con esta actualización del equipo de Snyk Security Research, seguimos con nuestra misión de brindar a los desarrolladores y equipos de seguridad una mejor forma de evaluar, priorizar y clasificar los problemas de seguridad, y fomentar un ciclo de vida de desarrollo más seguro y eficiente.

Las reglas y la gravedad de las reglas que utiliza nuestra versión más reciente de Snyk Infrastructure as Code (IaC), IaC+, se evaluarán según el CCSS. Como resultado, Snyk podrá ofrecer a sus clientes puntuaciones de riesgo más precisas para su infraestructura como código y sus configuraciones en la nube, basadas en la gravedad técnica (CCSS), la inteligencia de amenazas y el contexto de las aplicaciones y el negocio.

¿Qué significa la gravedad?

Los marcos estándar de la industria, como Common Vulnerability Scoring System (CVSS) y Common Configuration Scoring System (CCSS), nos ofrecen una metodología valiosa para puntuar vulnerabilidades y un lenguaje común para todos. Esto significa que los proveedores no tienen que inventar su propio marco y que los consumidores pueden comparar directamente a los proveedores sin la carga de traducir sus sistemas.

En pocas palabras, estos marcos definen varias métricas y un conjunto de fórmulas que convierten los valores de esas métricas en una puntuación de 0 a 10 y una gravedad correspondiente: baja, media, alta o crítica.

Tabla que muestra los niveles de gravedad y los rangos de puntuación de CCSS: Crítica 9.0–10.0, Alta 7.0–8.9, Media 4.0–6.9 y Baja 0.0–3.9.
Nivel de gravedad y puntuación

¿Qué es el Common Configuration Scoring System?

El Common Configuration Scoring System (CCSS) fue creado por el National Institute of Standards and Technology (NIST). Derivado del CVSS, se modificó para abordar problemas de configuración de seguridad del software. Como las configuraciones incorrectas de IaC son, en esencia, configuraciones de seguridad, podemos aplicarles el CCSS. 

La estandarización con CCSS aborda varios de los problemas mencionados anteriormente. Utiliza terminología, métricas y fórmulas conocidas y basadas en CVSS para asignar vectores a las configuraciones incorrectas de IaC, a partir de los cuales podemos determinar la puntuación y la gravedad de un problema. 

Así, en Snyk podemos reemplazar nuestro proceso anterior para asignar gravedad a las configuraciones incorrectas de IaC. Adoptar el estándar CCSS también permite a Snyk ser más transparente, al mostrar el vector, la puntuación y la gravedad sin que sea necesario un largo proceso de aprendizaje, tal como hacemos actualmente con las vulnerabilidades de CVSS.

Puntuación CVSS de 8.3, marcada como crítica, con vector de acceso local, autenticación múltiple y niveles de impacto indicados.
Panel de puntuación de CCSS que muestra una calificación crítica de 8.3, acceso local, autenticación múltiple, complejidad crítica, confidencialidad parcial, integridad completa y sin impacto en la disponibilidad
Desglose visual vectorial de CCSS (Próximamente)

El vector CCSS del problema anterior es `AV:L/AC:H/Au:M/C:P/I:C/A:N/PL:U/EM:A`. Esto nos da una puntuación base de `8.3` y una gravedad `High`. El gráfico anterior muestra las primeras seis métricas, pero no las dos últimas, `PL` y `EM`, es decir, `Privilege Level` y `Exploitation Method`, respectivamente. La razón principal es que estas dos métricas no afectan la puntuación base, aunque cumplen funciones importantes.

`Privilege Level` puede ser `User`, `Application`, `Root` o `Not Defined` e indica el nivel de acceso no autorizado que podría obtener un atacante. Para el vector base y la puntuación base, `PL` aporta información adicional a los consumidores y se usa al calcular ciertas métricas del entorno.

`Exploitation Method` es un poco más interesante, ya que los valores de muchas métricas base dependen del valor de la métrica `EM`. El valor de la métrica `EM` puede ser `Active` o `Passive`. Las configuraciones incorrectas `Active` exponen una vulnerabilidad que un atacante puede explotar, como permitir que los buckets de AWS S3 sean de acceso público de solo lectura o exponer una base de datos con una contraseña predeterminada para el usuario root. Las configuraciones incorrectas `Passive` se clasifican como aquellas que impiden que se realicen acciones autorizadas o que dificultan el trabajo de quienes defienden los sistemas. Algunos ejemplos son el registro de API desactivado o las copias de seguridad de bases de datos que no se conservan durante el tiempo suficiente. Las configuraciones incorrectas `Passive` suelen ser errores o incumplimientos de políticas que se mitigan rápidamente, mientras que las `Active` pueden ser más complejas y requerir más planificación y análisis.

¿Cómo implementamos CCSS en Snyk?

Snyk tiene un amplio conjunto de reglas de seguridad para revisar la seguridad de IaC y las configuraciones en la nube, con niveles de gravedad asignados mediante el proceso anterior. Agregar manualmente vectores CCSS, calcular puntuaciones y derivar nuevas gravedades sería una tarea tediosa. La creación de scripts ayudaría, pero carece de capacidad para tomar decisiones. ¡Por suerte, hay una mejor manera!

Al integrar IA en el proceso de implementación, agilizamos la adaptación de nuestro conjunto de reglas existente para que cumpla con los estándares CCSS. El uso de IA guiada por instrucciones y enriquecida con nuestra experiencia única garantiza que la gravedad de cada configuración incorrecta se determine de forma coherente y precisa. Este avance no solo mejora la transparencia y la confiabilidad de nuestras evaluaciones de seguridad para los usuarios, sino que también refuerza el compromiso de Snyk de liderar la industria con prácticas de seguridad centradas en los desarrolladores. 

Con nuestra experiencia previa en el uso de IA, nos pusimos manos a la obra para condensar la especificación CCSS en una instrucción, junto con pautas adicionales basadas en nuestra investigación. Tras analizar los resultados, la distribución de gravedad quedó así:

Gráfico circular titulado «Gravedad clásica» que muestra 49.7 % de gravedad media, 41.3 % baja, 8.9 % alta y 0.2 % crítica.
Porcentaje de reglas por gravedad

Y así quedó:

Gráfico circular titulado «Gravedad de CCSS» que muestra 82,0 % de gravedad media, 12,5 % alta, 4,2 % baja y 1,3 % crítica.
Porcentaje de reglas por gravedad de CCSS

Los gráficos anteriores muestran que nuestras calificaciones de gravedad anteriores de Snyk eran a menudo mucho más conservadoras que las del CCSS.

Estandarizar nuestro sistema de gravedad según CCSS no solo nos ofrece un proceso repetible para determinar la gravedad de las reglas, sino que también conserva datos contextuales valiosos para un análisis exhaustivo, como la puntuación de riesgo de Snyk. Además, el análisis de la distribución de las puntuaciones base en nuestro conjunto de datos revela un patrón de curva de campana. Esto coincide con la distribución estadística esperada para puntuaciones de 0 a 10 y reafirma la confiabilidad del método CCSS para generar evaluaciones de gravedad equilibradas y predecibles con tecnología de IA.

Gráfico de barras que muestra la distribución de las puntuaciones base de CCSS; las puntuaciones 5 y 6 tienen la mayor cantidad de reglas.
Distribución de puntuaciones base

¿Qué sigue para Snyk IaC?

Mantente al tanto de las actualizaciones de investigación de seguridad y del lanzamiento de la gravedad CCSS en updates.snyk.io.

Si quieres saber más sobre Common Vulnerability Scoring System (CVSS), que existe desde hace casi dos décadas, ya hemos hablado de él muchas, muchas veces.

Si quieres saber más sobre cómo se usa la IA como herramienta de desarrollo para complementar nuestro proceso de investigación de seguridad, escribimos sobre el tema aquí, e incluimos algunas prácticas recomendadas. 

Leer más

Blog

Los modelos de frontera encontraron las vulnerabilidades. Solo el atacante encontró las cadenas.

El análisis estático encontró las fallas, pero solo las pruebas de ataque en vivo demostraron cómo podían encadenarse para provocar brechas. Una comparación de Evo COS, Claude Security y Claude Code Security.

feature insights context
Blog

Los ataques autónomos ya están aquí. La defensa debe estar a su altura.

Los atacantes autónomos están reduciendo el tiempo disponible para defenderse. Descubre cómo el descubrimiento, la corrección, la validación y la prevención continuos pueden ayudar a los equipos de seguridad a seguirles el ritmo.

Blog

Por qué los agentes de programación con IA siguen generando fallas de control de acceso

Los agentes de programación con IA pueden generar lógica de autorización que compila y supera la revisión, pero expone los datos de un inquilino a otro. Descubre por qué es difícil detectar el control de acceso roto y cómo prevenirlo.