Por qué la clasificación de alertas podría desaparecer

Si hay un aspecto que se puede mejorar en el ámbito de la seguridad en general, es su reputación de frenar a las organizaciones.

Uno de los principales culpables de esta reputación es la «clasificación de alertas»: el proceso de validar si una alerta de seguridad realmente afecta a tu organización, estimar su impacto y determinar cómo resolverla.

En este artículo, analizaremos por qué la clasificación de alertas puede convertirse rápidamente en un cuello de botella para las organizaciones y plantearemos que todos deberíamos aspirar a omitirla y enfocarnos en corregir las vulnerabilidades.

Un flujo de trabajo de clasificación de alertas ejemplar

Imaginemos cómo podría ser el flujo de trabajo para clasificar una alerta de seguridad sobre una vulnerabilidad recién detectada.

Tomemos como ejemplo la reciente vulnerabilidad RCE (ejecución remota de código) en Apache Struts, que finalmente se explotó en el caso de Equifax. Podemos imaginar cómo podría abordar una vulnerabilidad así una empresa de ese tamaño:

• Alguien del equipo de seguridad recibe una alerta sobre la existencia de la vulnerabilidad. Esto supone que está suscrito a las listas de correo pertinentes o que usa herramientas que le avisan sobre ella (¡y que también lee esas alertas!).

• Esta persona del equipo de seguridad le pediría a un ingeniero que generara un informe de todas las aplicaciones del portafolio de la empresa que usan Apache Struts. Esto, por sí solo, no es una tarea sencilla, ya que administrar el inventario y la composición de los sistemas es todo un desafío, sobre todo para las empresas que llevan mucho tiempo operando. La situación se complicaría aún más en el caso de empresas que han realizado fusiones y adquisiciones y que, con los años, han comprado varios equipos que usan diferentes pilas tecnológicas. Aun así, supongamos que la organización pudo generar un informe con 100 proyectos que usan Apache Struts.

• La persona del equipo de seguridad crearía 100 tickets en Jira con la gravedad «crítica» y activaría la política de máxima prioridad de la empresa para resolver el problema de inmediato.

• Habría que localizar a 100 ingenieros de distintas áreas de la organización y asignarles la tarea de corregir esta vulnerabilidad.

Ahora imaginemos cómo se ve la situación desde la perspectiva de los desarrolladores. Lo más probable es que estén trabajando en una funcionalidad de alto valor y quieran terminarla rápido para cumplir un hito comercial importante o una fecha límite. Aun así, se trata de una alerta de seguridad importante, así que tendrán que atenderla. Estos son los pasos que tendrían que seguir:

• Leer sobre la vulnerabilidad en cuestión.

• Leer y aprender sobre la ejecución remota de código y la clase de vulnerabilidad en sí.

• Intentar averiguar si la vulnerabilidad afecta a su aplicación en particular. Quizás tengan que encontrar el exploit real y confirmar si es aplicable.

• Investigar cuáles son las posibles soluciones para esta vulnerabilidad.

• Aplicar las soluciones.

• Confirmar que eliminaron la vulnerabilidad.

Es mucho trabajo, y parte requiere conocimientos especializados en seguridad. Todo el flujo de clasificación de alertas podría tomar días, semanas o incluso meses, según lo complejos que sean los procesos internos de la empresa. Y eso no es bueno.

¿Podemos crear software que ayude a clasificar las alertas?

¡Probablemente! Con algo de instrumentación de código y aprendizaje automático, podríamos crear un sistema que te indique si hay rutas de código que usan el método vulnerable de las bibliotecas que contienen las vulnerabilidades. Si funciona con precisión (es decir, con pocos falsos positivos y falsos negativos), reduciría algunos de los pasos de clasificación para los desarrolladores. Sin embargo, incluso si demostramos que la vulnerabilidad se puede explotar en nuestro contexto, ¡el desarrollador seguiría teniendo que averiguar cómo corregirla!

A menudo, lo que resulta más peligroso es que las herramientas nos sugieran que, en el contexto actual, quizá no haya flujos de datos que permitan explotar la vulnerabilidad. En estos casos, muchas organizaciones suprimen o ignoran la alerta, y ahí es donde reside el peligro.

Que el código no tenga flujos de datos vulnerables ahora no significa que no los vaya a tener mañana. Un método que hoy no se ejecuta podría ejecutarse después del próximo commit de un desarrollador. Es probable que el siguiente desarrollador no tenga forma de saber que hay un método vulnerable oculto en la biblioteca que usa, ni que la alerta se suprimió porque ese método no se ejecutaba hasta ahora. Basar tu postura de seguridad en la premisa invariable de que el método no se ejecuta hoy es casi una imprudencia.

Si vemos el panorama general, la clasificación de alertas no es más que un paso previo a la corrección de las vulnerabilidades. Se recurre a ella porque se percibe que corregirlas es difícil y requiere mucho trabajo. Pero ¿qué pasaría si, en lugar de usar software para ayudar a clasificar las alertas, nos saltáramos todo eso y usáramos software para automatizar las correcciones?

¡Los pull requests de alertas de Snyk son lo máximo!

Cuando agregas tus proyectos a Snyk, mantenemos un inventario preciso y continuo de todas tus dependencias. Por eso, cuando se divulga una vulnerabilidad importante como la RCE de Apache Struts, podemos alertarte en tiempo real. Y lo que es más importante, podemos decirte exactamente cuáles de tus aplicaciones tienen la vulnerabilidad. Si conectas Snyk con tu administrador de código fuente (como Github, Gitlab o BitBucket), podemos hacer aún más: enviar un pull request con la corrección directamente a los repositorios afectados.

Para eliminar la vulnerabilidad de tu código, solo tienes que aprobar el pull request. Corregirla es lo indicado, independientemente de que tus flujos de datos ejecuten ese código hoy o no.

No solo se puede reemplazar todo el flujo de clasificación de alertas por un solo botón de «aceptar» en el pull request, sino que también se reduce el nivel de conocimientos especializados en seguridad que necesita la organización para implementar las correcciones. Seguridad simple y rápida: eso sí que está muy bien.