Gestión de vulnerabilidades

Realizar un proceso de gestión de vulnerabilidades es un trabajo minucioso en el que se han de analizar y detectar las ventajas de cada paso

Cuando hablamos de gestión de vulnerabilidades, muchos pensarán que nos estamos refiriendo a llevar un seguimiento de qué se ha detectado, cómo de grave era y si está o no corregido.

Es cierto que estos puntos son importantes y que un proceso de gestión de vulnerabilidades debe contar con ellos. Sin embargo, muchas veces hay otros que se pasan por alto o en los que se decide no dedicar recursos.

Esto suele ocurrir porque no se ve en ellos un beneficio claro. La idea de este post es identificar algunos de ellos y analizar las ventajas que nos pueden aportar.

El catálogo de activos

El primer paso para controlar las vulnerabilidades en una organización es tener claro sobre qué se va a trabajar, es decir, en un entorno software, cuáles son las aplicaciones que hay en la casa y qué características tienen.

A veces es complicado incluso definir qué es una aplicación, y esta problemática tiene mucho sentido, ya que en cada organización se tratan los desarrollos de una forma diferente.

Por lo general, supondremos que una aplicación es un conjunto de funcionalidades interrelacionadas que tienen un objetivo común y que comparten una serie de características tecnológicas.

Una vez clara la unidad mínima sobre la que trabajar (la aplicación), es interesante contar con un inventario o catálogo de activos. ¿Por qué?

Priorización

Es muy útil establecer una categorización de los activos según su importancia para el negocio, la sensibilidad de los datos con los que trabaja, etc.

No será igual una vulnerabilidad en la aplicación que gestiona la reserva de plazas de aparcamiento de los empleados, que la que gestiona los pagos de nuestros clientes. Esta parte irá íntimamente relacionada con el tiempo que se exigirá a la resolución de una vulnerabilidad.

Estado de salud de los activos

Partiendo de la información de las vulnerabilidades de los activos, y de ciertos parámetros adicionales, se puede calcular el estado de salud de los activos: una métrica desarrollada por nuestro equipo de Ciberseguridad que expresa el nivel de seguridad de los activos de forma cuantitativa.

Asignación de responsabilidades

Una aplicación suele estar desarrollada por un equipo, y este equipo es el responsable de remediar las vulnerabilidades que se detecten en ella. Cuando las aplicaciones no están claramente definidas y delimitadas, podemos tener dudas sobre quién es el responsable de arreglar una nueva vulnerabilidad.

Al tener un catálogo de activos en el que cada aplicación esté asignada a un equipo de desarrollo, quedará muy claro qué equipo es responsable de arreglar una nueva vulnerabilidad cuando se detecte e incluso será posible automatizar este proceso.

Casos de uso avanzados

Si reunimos las características tecnológicas de nuestras aplicaciones en el catálogo de activos, cuando en una auditoría de seguridad web se detecte una vulnerabilidad en un componente, seremos capaces de establecer qué aplicaciones son vulnerables y cómo afecta eso al riesgo de la organización.

Otro caso de uso avanzado sería la posibilidad de priorizar mejoras según el impacto global; tal vez podamos corregir un defecto en múltiples aplicaciones si abordamos algo común que les afecta a todas.

¿Por dónde empezar?

Esto sería genial, pero no tengo un catálogo y no parece que lo vaya a poder tener mañana… ¡Roma no se construyó en un día! Y esto tampoco tiene por qué.

Una buena forma de construir un catálogo de activos es establecer hitos en el ciclo de vida en los que sea necesario un paso por seguridad. De esta manera, se pueden identificar las aplicaciones y sus características a la vez que se realizan los análisis de seguridad pertinentes, e ir poco a poco.

Si le damos una vuelta de tuerca más y ligamos la aprobación del presupuesto de las aplicaciones a la superación del primer hito de seguridad, habremos blindado el onboarding en nuestro catálogo de activos.

Por supuesto, también se puede ejecutar un proyecto de inventariado de aplicaciones, todo depende de la urgencia y los recursos disponibles.

Trazabilidad en la gestión de vulnerabilidades

Cuando se reporta una vulnerabilidad crítica en producción sobre una aplicación importante para el negocio, lo normal es que se resuelva inmediatamente.

Haciendo el símil de un coche, este sería el equivalente a llevar el motor en llamas. Puede que no explote, pero nadie quiere esperar a comprobarlo. Sin embargo, no es nada raro que unos cuantos fallos mecánicos, que en principio parecían leves, resulten en una avería importante.

Con la seguridad pasa igual. No se trata de prestarle atención al coche sólo cuando el motor está en llamas, sino de ir arreglando las averías pequeñas para que no se conviertan en graves, e incluso tomar acciones preventivas para que estas no lleguen a ocurrir.

Cuando estamos centrados en el delivery, es fácil que no resolvamos todos los defectos de seguridad si estos no son de una importancia alta.

Siguiendo con el símil del coche, sería como si vemos que tenemos las ruedas desgastadas y lo dejamos estar porque tenemos la semana liada. Vemos que los limpias no funcionan bien pero, como es verano y no llueve, no los reemplazamos, etc. Incluso podría ocurrir que llevemos el coche al taller para un cambio de aceite y ni nos acordemos de estas cosas.

Para evitar una situación así, una estrategia que podríamos adoptar consistiría en, asignar una criticidad, un responsable, y fijar una fecha para la resolución y gestión de vulnerabilidades según son reportadas.

De esta forma acabaremos por resolverla, e iremos reduciendo progresivamente nuestra deuda técnica de seguridad en lugar de ampliarla.

Muchas veces, estaremos sometidos a una regulación que nos obligará a tener registros y métricas sobre nuestras vulnerabilidades. Para evitar tener que recabar toda la información antes de la auditoría, es aconsejable emplear sistemas de gestión de vulnerabilidades.

Existen diferentes aproximaciones, y cada una será válida para un tipo de cliente y su volumen de aplicaciones.

Idealmente, si se tienen muchas aplicaciones y un entorno industrializado, se apostará por la implantación de un gestor de defectos, pero habrá situaciones en las que podamos funcionar con una hoja de cálculo.

Todo dependerá de los procesos y las necesidades de negocio antes que de las herramientas que los implementen.

Unificar los resultados de distintos procesos de análisis

Lo más seguro es que contemos con distintos mecanismos que sean capaces de identificar defectos de seguridad en nuestro software para dar cobertura a los distintos escenarios de ataque y construir un modelo de seguridad en profundidad:

• Auditorías de código fuente (SAST)
• Análisis dinámico (DAST)
• Pentests manuales
• Servicios de Bug Bounty
• Ejercicios de Red Team

Es complicado gestionar la seguridad de las aplicaciones teniendo que revisar el output de cada uno de estos procesos de forma manual, además de que se pierde la perspectiva global.

Sin embargo, centralizando todos los defectos de seguridad (por ejemplo, en un gestor de defectos), seremos capaces de tener una perspectiva global del activo sin necesidad de revisar distintas plataformas.

Todo ello nos ayudará a priorizar y a obtener métricas centradas en el activo y no en el proceso de análisis.

SLAs

Uno de los puntos clave para asegurar que las vulnerabilidades se resuelven es asignar responsables y establecer procedimientos que fijen plazos de resolución.

Para ello, generalmente se tienen en cuenta tanto la criticidad de la vulnerabilidad como la relevancia del activo.

Pero si somos la persona responsable de gestionar el proceso de resolución de vulnerabilidades, probablemente llevar la cuenta de los vencimientos de SLAs y notificar a sus responsables del incumplimiento sea una de las últimas cosas en la que queramos invertir energía.

¿Y si esto se hiciera de forma automática? Existen soluciones que nos permiten llevar un seguimiento en tiempo real de los plazos y le recuerdan a su responsable que aquella vulnerabilidad de criticidad baja que le reportaron hace cinco meses está a punto de vencer.

Hacer un seguimiento de los proyectos que presentan mayores índices de incumplimiento de los acuerdos de nivel de servicio es otro punto a tener en cuenta, ya que nos permitirá detectar posibles gaps de los equipos de desarrollo y trazar una estrategia para cubrirlos.

Métricas

El proceso de gestión de vulnerabilidades genera una información que, analizada correctamente, puede ser muy valiosa. A continuación, hablaremos sobre algunas métricas que podríamos obtener de él y los beneficios que nos pueden reportar:

Riesgo Dinámico de Seguridad

El Riesgo Dinámico de Seguridad es una metodología desarrollada por el equipo de Ciberseguridad de Tarlogic que nos permitirá determinar, mediante distintas métricas, cómo las vulnerabilidades presentes en la tecnología producen un impacto que afecta no sólo a la propia tecnología, sino también a la información que almacena y procesa.

Esto se debe a la relación existente entre tecnología e información.

Los defectos más comunes

Cada equipo de desarrollo trabaja de una manera, tiene un expertise distinto, emplea una tecnología u otra, y esto deriva en que los defectos de seguridad más comunes varíen entre una organización y otra, e incluso entre equipos de la misma compañía.

Identificarlos nos puede permitir programar trainings o workshops enfocados en la prevención de las vulnerabilidades más comunes de un equipo de desarrollo.

De esta manera, mediante la formación y la concienciación, se puede conseguir reducir su aparición y, lo que es más importante, de su coste de resolución.

Mejorar las actividades de detección

Cuando una vulnerabilidad se materializa de forma reiterada, puede ser interesante diseñar un procedimiento para su detección.

De esta forma, Seguridad se puede apoyar en los equipos de desarrollo para que realicen verificaciones básicas antes de las auditorías, o incluso se pueden automatizar revisiones periódicas.

Dimensionar los equipos

El dimensionado de equipos es una tarea delicada. Apoyándonos en métricas de gestión de vulnerabilidades podemos, por ejemplo:

• Establecer si los equipos de desarrollo son capaces de seguir el ritmo de corrección de las vulnerabilidades reportadas a partir de los datos del volumen de vulnerabilidades reportadas y corregidas.
• Determinar si las revisiones de seguridad están suponiendo un cuello de botella en la cadena de producción o si,  por contra, se está pudiendo seguir perfectamente el ritmo de las releases.

Implementación del modelo de gestión de vulnerabilidades

Dependiendo del modelo del que se parta, será necesario trabajar distintos aspectos para avanzar el modelo de gestión de vulnerabilidades del que se disponga.

Puede que, en algunos casos, el procedimiento esté muy bien definido, pero no se haya encontrado una manera de aterrizarlo de forma ágil, en cuyo caso tiene sentido estudiar en qué herramientas podemos apoyarnos para implementar nuestro modelo.

Existen soluciones, tanto comerciales como open-source (por ejemplo, DefectDojo), que facilitan la gestión de vulnerabilidades y permiten implementar casi todas las ideas que se han expuesto en este post.

Por otro lado, podríamos estar satisfechos con nuestra herramienta, pero no tanto con el procedimiento.

Una señal de esto podría ser que nos encontremos de forma recurrente con el mismo problema, por ejemplo, con nuestro modelo de datos a la hora de unificar el input de distintas herramientas, con los pasos a seguir cuando se detecta una vulnerabilidad…

Esta situación se asemeja bastante a ir caminando con una piedra en el zapato. Sabemos que estamos incómodos, pero tenemos que seguir caminando y, de alguna manera, nos hemos acostumbrado a esa incomodidad.

Para remediarla, tendría sentido que nos parásemos a buscar la piedra, y la sacásemos del zapato. Lo que sería analizar nuestro proceso de gestión de vulnerabilidades, encontrar los puntos de mejora y trabajar sobre ellos hasta obtener un proceso ágil en el que todo quede definido.

¿Podemos ayudarte?

En Tarlogic Security hemos trabajado con distintos clientes en la mejora de su sistema de gestión de vulnerabilidades, partiendo de un análisis inicial, planteando mejoras incrementales para trabajar su nivel de madurez, y buscando la herramienta que más se adapte al modelo desarrollado.

Si crees que podemos ayudarte, no dudes en contactar con nosotros.

Descubre nuestro trabajo y nuestros servicios de ciberseguridad en www.tarlogic.com/es/

En TarlogicTeo y en TarlogicMadrid.