Cómo gestionar un sistema eficaz de tickets de vulnerabilidades con Ostorlab

Descubrir vulnerabilidades es solo el comienzo de un camino, a menudo largo, para corregir, desplegar y validar las correcciones de seguridad.

Este camino puede volverse tedioso rápidamente si no se dispone de las herramientas adecuadas para agilizar el proceso e integrar la detección, la corrección y la validación de las correcciones en el ciclo de vida de la gestión de la corrección.

Los sistemas de tickets tradicionales suelen requerir un esfuerzo manual considerable para clasificar los nuevos problemas, identificar duplicados y gestionar los falsos positivos. En las grandes organizaciones, a veces hay una persona o un equipo dedicado exclusivamente a clasificar los hallazgos de los escáneres y a asegurarse de que se eliminen los duplicados. Una tarea poco glamurosa que muchos temen enormemente.

Según un estudio de 2022 realizado por ServiceNow, las organizaciones dedicaban una media de 443 horas semanales a actividades de gestión de vulnerabilidades, el equivalente a unos 11 empleados a tiempo completo.

Una de las funcionalidades centrales de la plataforma Ostorlab es su completo sistema de tickets, diseñado a medida para la gestión de vulnerabilidades. Se ha construido y concebido desde cero para afrontar los retos de gestionar el ciclo de vida de la corrección de vulnerabilidades.

El sistema de tickets de Ostorlab se lanzó en octubre de 2021. Ha ayudado a más de 10.000 organizaciones a automatizar y agilizar todo el proceso de gestión y corrección de vulnerabilidades de seguridad.

Las funcionalidades principales del sistema de tickets de Ostorlab incluyen:

• Generar automáticamente tickets para las vulnerabilidades recién detectadas e incorporar información detallada, como el tipo, la severidad y el contexto.
• Agregar las vulnerabilidades recurrentes en un único ticket mediante un identificador único (DNA),
• Las vulnerabilidades corregidas se verifican automáticamente mediante nuevos escaneos, lo que garantiza que los problemas se resuelven de forma eficaz.
• Aplica políticas de aplicación de parches con objetivos de nivel de servicio (SLO), como resolver los problemas de severidad alta en cinco días.
• La compatibilidad sin fricciones con herramientas como Jira permite a las organizaciones gestionar las vulnerabilidades dentro de sus flujos de trabajo actuales.

En 2024, los clientes de Ostorlab tuvieron un tiempo medio de corrección (MTTR) de 17 días, con solo 5 días para los problemas críticos y 10 días para los problemas de seguridad altos.

Si bien la versión inicial del sistema de tickets aportó un enfoque innovador para agregar tickets basándose en un DNA único, los comentarios continuos de los usuarios ayudaron a identificar nuevos retos a los que se enfrentan los desarrolladores y los equipos de seguridad al gestionar las vulnerabilidades en distintos entornos y plataformas.

Hoy anunciamos el lanzamiento de la versión 2 del sistema de tickets de Ostorlab, que aborda esos retos y aporta más flexibilidad a la forma de agregar tickets entre distintos entornos y plataformas.

Los retos

Hacer un seguimiento del estado de una vulnerabilidad en múltiples versiones y plataformas es difícil y puede dar lugar a esfuerzos de corrección incoherentes.

Por ejemplo, si tiene una aplicación móvil en Android e iOS, el ciclo de vida de desarrollo de la aplicación suele tener cuatro etapas: versión de desarrollo, staging, pre-prod y prod.

En este escenario, una sola vulnerabilidad podría generar hasta 8 tickets distintos (2 plataformas x 4 etapas del ciclo de vida), lo que supone una complicación logística para los equipos de seguridad que intentan gestionar y corregir los problemas de forma eficaz.

Este enfoque fragmentado suele provocar que las vulnerabilidades se corrijan de forma incoherente en distintos entornos o plataformas. Por ejemplo, un fallo de seguridad crítico podría corregirse con un parche en la versión de producción de Android, pero pasarse por alto en el entorno de staging de iOS.

¿Cómo resuelve estos problemas la versión 2 del sistema de tickets de Ostorlab?

En lugar de usar una lógica predefinida para agregar los tickets, los usuarios ahora pueden definir cómo desean agrupar las vulnerabilidades entre distintas plataformas o entornos.

Caso de uso 1:

• Tenemos una aplicación móvil en Android e iOS.
• Subimos los archivos APK o IPA para escanear nuestras versiones de desarrollo
• Escaneamos desde PlayStore y AppStore para escanear la versión de producción.

-> Queremos tener un ticket para cada entorno y plataforma.

Para ello, puede definir una agrupación por plataforma y colocar cada entorno en un grupo distinto:

Caso de uso 2:

• Tenemos una aplicación móvil en Android e iOS.
• Subimos los archivos APK o IPA para escanear nuestras versiones de desarrollo
• Escaneamos desde PlayStore y AppStore para escanear la versión de producción.

-> Queremos agrupar los tickets de Android procedentes de la tienda o del archivo. Lo mismo se aplica a iOS. Sin embargo, si un problema se corrige en el archivo de Android, el ticket debe permanecer abierto hasta que la corrección llegue a la versión de la tienda.

Para ello, puede definir una agrupación por plataforma y colocar cada entorno en un grupo distinto:

Caso de uso 3:

• Tenemos una aplicación móvil en Android e iOS.
• Tenemos distintos entornos para los archivos APK e IPA:
  • Dev: com.myapp.dev
  • QA: com.myapp.qa
  • Prod: com.myapp.prod
• Escaneamos desde PlayStore y AppStore para escanear la versión de producción.

-> Queremos agrupar los tickets de Android procedentes de la tienda o del archivo en todas las versiones de los entornos. Lo mismo se aplica a iOS. Sin embargo, si un problema se corrige en el archivo de Android, el ticket debe permanecer abierto hasta que la corrección llegue a TODAS las versiones.

Para ello, puede definir una agrupación por ID de aplicación y colocar cada ID de aplicación en un grupo:

Caso de uso 4:

• Distribuimos nuestra aplicación móvil en Android e iOS con marca blanca.
• Tenemos distintos clientes para los archivos APK e IPA:
• Android: com.android.myapp.customer
• iOS: com.ios.myapp.customer

-> Queremos agrupar en un solo ticket los tickets de Android de las aplicaciones de marca blanca.

Este caso de uso es similar al caso de uso 3, ya que solo hay que definir un grupo con todos los ID de aplicación. Por ejemplo, aquí añadimos un grupo con la expresión regular del cliente.

Conclusión

La versión 2 del sistema de tickets de Ostorlab introduce flexibilidad para que los usuarios puedan definir la lógica de agregación que se ajuste a su flujo interno.