Este título es deliberadamente ambiguo. “Tener una vulnerabilidad” puede significar desde sufrirla a conocerla. Y en medio hay un buen montón de pasos intermedios que merece la pena entender. La industria alrededor de la ciberseguridad se basa, en buena parte, en el análisis del lado en el que se está con respecto a una vulnerabilidad. Es una piedra angular que ofrece una buena perspectiva sobre los diferentes intereses generados hacia este “activo”.

Las vulnerabilidades son fallos o debilidades que permiten a un atacante comprometer la seguridad de un sistema informático. Principalmente pueden ser causadas por errores de diseño, de programación o de configuración. Más claro: son un fallo en software que puede ser aprovechado para atacar al sistema o usuario que lo aloja. Es como tener acceso exclusivo a un atajo, una llave maestra para controlar un servidor o un sistema operativo. Conocer a tiempo una vulnerabilidad y cómo aprovecharla confiere más poder cuanto más popular es el software que la sufre. Y ante la gestión de una vulnerabilidad, hay muchas aproximaciones y procesos asociados además de, al menos, seis actores diferentes.

El primero: El responsable del software que contiene la vulnerabilidad. El programador o empresa que se ocupa del software y, por error, introduce un fallo que permite a un atacante cambiar su comportamiento y aprovecharlo para robar, ejecutar otro programa, etc. Desde el principio de los tiempos de la informática, muy pocos fabricantes se han responsabilizado de estos fallos más allá de un compromiso para parchearlos (anular la vulnerabilidad). La inmensa mayoría de los creadores de software indican en sus términos de uso que no son responsables de las vulnerabilidades encontradas y tampoco de sus consecuencias. No hay regulación clara al respecto. Desde hace años premian a los investigadores que encuentran sus fallos, pero, anteriormente, podían desde denunciarlos hasta ofrecerles una camiseta por un trabajo que hoy vale decenas de miles de euros. Para los responsables del software, la vulnerabilidad es un activo tóxico y les interesa solucionarla discretamente cuanto antes.

El segundo: Los estados y gobiernos. Por ahora regulan “los aledaños” de la industria del software y sus errores. Esto significa que promocionan o crean (y a veces exigen y otras recomiendan) metodologías de desarrollo seguras. También pueden obligar a hacer públicas las consecuencias de las vulnerabilidades (como, por ejemplo, comunicar una exfiltración de datos). Pero legalmente, en general, introducir involuntariamente una vulnerabilidad en un software que pueda causar pérdidas millonarias en el mundo no tiene consecuencias penales ni administrativas. Solo reputacionales. Cuando el software es libre y gratuito, hay organizaciones que recompensan a los investigadores por encontrar fallos en el software más popular. La UE, por ejemplo, tiene un programa para ello. También suelen disponer de organizaciones que alertan de las vulnerabilidades y animan al parcheo. En resumen, gestionan la vulnerabilidad a través de la regulación e incentivos a los investigadores para crear entornos seguros para el ciudadano.

El tercero: Los investigadores. Antes, poco respetados por su trabajo y, ante la falta de alternativas, podían llegar a vender el conocimiento del fallo a los atacantes. Otros, con más escrúpulos, terminaban por comunicar el problema a las grandes compañías de software de forma altruista. Pero se cansaron. Es un trabajo que requiere mucha investigación. Para los que solo querían reputación y crédito por encontrarlos podía ser suficiente, pero muchos otros demandaban un trato digno. Comenzaron a presionar haciendo “full disclosure” de los fallos. Esto es publicándolos con todo lujo de detalles sin previo aviso para medrar en la reputación de la compañía y presionar para su arreglo. Pero, desde hace unos 15 años, casi todas las grandes plataformas o desarrolladoras de software pagan a los investigadores según la gravedad del fallo encontrado. Muchas directamente. Pero otras tantas pequeñas no tienen esa posibilidad. Para el investigador, la vulnerabilidad es un activo muy valioso que intercambiar.

El cuarto: los brokers. Para las empresas que no gestionan ellas mismas un programa de recompensas por vulnerabilidades surgen los brokers. Son plataformas que se encargan de recopilar, a través de una única página, todo el proceso de descubrimiento del fallo: ponerle precio, comunicarse con la compañía afectada… Así el investigador tiene un único punto de gestión y los brokers se encargan de todo. Reparte millones entre los que participan. ¿Qué ganan los brokers? Muchas veces una comisión, pero también pueden llegar a conocer fallos en exclusiva mucho antes que otros y eso es un valor en sí mismo.

El quinto: Las agencias de inteligencia. La última tecnología en inteligencia no son misiles, aviones de combate o fragatas. Son vulnerabilidades en software conocido que podrían permitir espiar un teléfono, operar una central nuclear o controlar un sistema operativo. Los gobiernos disponen de este arsenal. Cómo lo usen, con qué frecuencia y contra quién, suele ser secreto.

El sexto: Los atacantes quieren esas vulnerabilidades para robar y que no sean parcheadas. Para ellos son munición muy valiosa. Ofrecen más dinero a los investigadores para que no las comuniquen a los brokers o empresas afectadas. Los atacantes más sofisticados pueden disponer de sus propios investigadores a sueldo para encontrarlas. Les interesa mantenerlas en total secreto mientras las usan y “quemarlas” lo menos posible en las operaciones. Sus peores enemigos son las empresas de ciberseguridad que, cuando investigan los ataques, suelen encontrar estos fallos y comunicarlos a los afectados para que los arreglen.

Los contrapesos que ejercen unos sobre otros en este ecosistema constituyen el equilibrio actual de la ciberseguridad. Si bien se ha mejorado enormemente desde los tiempos en los que se comunicaban sin previo aviso y públicamente vulnerabilidades gravísimas en internet, todavía quedan muchos flecos por solucionar. Como, por ejemplo, la responsabilidad de los creadores de software. Porque quizás no nos parezca importante un fallo en programa de gestión, pero… ¿qué consecuencias tiene una vulnerabilidad en un software que gestiona una central nuclear? ¿Y en el software de un marcapasos?

Por ahora, con estos avances en el statu quo, se ha conformado un clima de colaboración entre la comunidad de investigadores y las organizaciones creando una cultura de transparencia y confianza, arrinconando con ello a los atacantes que deben invertir cada vez más para encontrar un fallo jugoso.