Talento vs KPI: Una muerte es una tragedia, un millón, estadísticas

Para lidiar con una vulnerabilidad hay que primero comprenderla, hacer una POC y que funcione, cuantificar cuál es su impacto teórico en términos de Confidencialidad, Integridad y Disponibilidad  y otras dimensiones, por ejemplo aplicando CVSS. Luego, desarrollar algún método de detección, que puede ser tan sencillo como comprobar la versión de una librería a un sofisticado script, programa o plugin de alguna herramienta de seguridad como NMAP o Metasploit que interactúe con el sistema y la explote, preferentemente sin generar efectos colaterales perjudiales. En caso de haber un payload involucrado, desde comprender su funcionamiento a desofuscarlo en caso de lenguajes interpretados hasta una dificilísima ingeniería inversa ya que se trata código de máquina, que puede estar cifrado y ofuscado y nos lleva al hostil terreno del assembly y el conocimiento íntimo del sistema operativo, sin dejar de lado un sencillo análisis de comportamiento en busca de IOCs para alimentar herramientas de detección y prevención.

Habíendo superado esta etapa, evaluar en nuestro despliegue actual según la situación perimetral, la topología de la red, el valor de la información, en otras palabras, un análisis complejo de amenazas para poder determinar el potencial efecto real de esa vulnerabilidad en los distintos puntos del sistema donde puede estar presente y elegir el mejor plan de mitigación, que puede ser eliminar funcionalidades o aplicaciones, aplicar parches o actualizaciones, cambiar valores de configuración, agregar o modificar reglas de IPS, WAF, AV y FW.

A todo esto lo considero Talento, tanto desde la actuación de la gente ciberseguridad en la primera etapa como en la segunda que se suma la de gente de desarrollo, sistemas y administración de seguridad.

 
Hay otro Talento, que es del lado de la arquitectura, diseño y programación de las aplicaciones y servicios. Desde ese punto de vista, hay una inteligencia y optimización orientada a no hacer esfuerzos innecesarios, a intentar comprender. 

Entonces si el reporte de vulnerabilidades dice que hay tal componente vulnerable, correctamente, en lugar de salir corriendo a actualizarlo, este Talento dice, veamos si lo estamos usando de modo tal que la vulnerabilidad se manifieste. Por ejemplo, con Log4Shell, este Talento pregunta, ¿estamos enviando mensajes que vienen desde el usuario al log? Por que si no es así, no hay vulnerabilidad concreta, por favor no me hagas perder mi magro tiempo actualizando algo que no hace falta.
 

En la confluencia entre ambos Talentos, para que ciberseguridad pueda realmente apreciar el impacto de una vulnerabilidad en los sistemas necesita un importante esfuerzo por parte de las demás áreas técnicas.
 

Ahora, imaginemos que no tenemos una sola vulnerabilidad sino que tenemos miles, si, miles, que combinadas con nuestros activos generan combinaciones de centenares de miles de instancias, quizás millones.
 

Poco podemos conservar de la visión enunciada, es como una herida abierta esperando a infectarse, hay que limpiar y proteger, rápido, luego vemos si antibiótico, vendas, reposo. Miles de heridas.
 

Mientras aplicamos las defensas perimetrales, por madurez podríamos intentar identificar esas instancias, pues se dice que es indispensable medir… tarde, ese tiempo es tiempo cedido al atacante.
 

Las vulnerabilidades propias de nuestros sistemas descubiertas por Ethical Hacking pueden esperar un poco, apelando a una falsa seguridad por oscuridad, al atacante le puede costar encontrarlas pues debe interactuar con nuestro sistema. Pero con las que corresponden a elementos de terceros no hacen falta sutilezas, descubrirlas es simplemente correr un script sin ningún pensamiento.
 

Eternal Blue es un ciberataque que encarnado en el ransomware Wannacry es la prueba viviente. En abril de 2017 The Shadow Brokers la publicó tras habérsela robado a la NSA, que la había descubierto cerca de cinco años antes. En mayo de 2017 fue la primera oleada de ataques de la mano del ransomware Wannacry. En marzo de  2017 Microsoft publicó el patch, advertidos por NSA. Casi dos meses transcurrieron desde la disponibilidad del parche hasta su explotación masiva. Una política proactiva de actualización la hubiese convertido en Wannabe.
 

No he oido de explotaciones masivas de Log4shell, algo se ha aprendido desde Wannacy, pues hasta donde he sabido las políticas han sido más o menos:
 

• En el perímetro se detecta y bloquea cualquier intento de explotación y postexplotación, rápido.
• Se dan de baja aplicaciones.
• Se actualizan las librerías.
• Se aplican mitigaciones por configuración.

 

Estas dos últimas medidas pueden parecer quizás un tanto desprolijas, pero para hacerla correctamente hay que usar Talentos, lo cual hubiese sido un desperdicio.

Hay que aplicar los parches con la única consideración de que los sistemas sigan funcionando, no si hace falta. No va más “si funciona no lo toqués”, ni siquiera hay que esperar a que se detecte que un componente tiene una vulnerabilidad para actualizarlo. Hay que hacerlo permanentemente, quizás no el mismo día que sale cada parche, pero si con una frecuencia muy alta.

Eso pulirá los mecanismos de los equipos de DevOps para afrontar cualquier actualización de urgencia real.
 
Se parece un poco al sistema Chaos Monkey de Netflix, donde a propósito se voltean al azar componentes en producción para forzar a que el sistema de conjunto sea resistente a fallas.

Una deuda, razonable y con paralelismo en Kanban es la de los vulnerabilidades de bajo impacto, equivalentes a las tareas de baja prioridad. En Kanban incluso existe un mecanismo de purga del backlog con el criterio de que si pasaron tantos meses y no se han resuelto ciertas tareas de baja prioridad, entonces no deben tener tanto valor y si lo tienen, renacerán pronto. La vulnerabilidades de bajo impacto que no son resultado de la construcción de nuestro sistema, o sea, las de librerías de terceros y sistemas operativos de soporte, del mismo modo persisten meses o años, pero tienen una diferencia, si se aplica al política de actualización permanente, simplemente disminuirán drásticamente de la mano de las importantes, sin que las hayamos atacado explícitamente.

No me gustan los KPIs, pienso que son dimensiones sacadas de la galera, yo elaboro unos, otra persona otros, seguramente incompatibles e incongruentes. Representan los intereses de distintos Product Owners que quizás estén en conflicto de intereses. No importa, los podemos poner a nuestro servicio, debemos tener menos de tantas vulnerabilidades por equipo, de acuerdo aunque desde el punto de vista del Talento parece ser una muestra de ceguera atroz. Una vez que se reducen los números, podemos recuperar el Talento y comenzar a pensar como atacar las vulnerabilidades más especiales.

El uso de los KPI y la aplicación de parches aparentemente con poca inteligencia, es economía de escala.