¿Es HEIST un riesgo o una amenaza?

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Los profesionales de la seguridad deben comprender la diferencia entre riesgos y amenazas y actuar en consecuencia. Para quienes no somos expertos (es decir, la mayoría), puede parecer que no existe diferencia alguna entre ambos conceptos. Al fin y al cabo, ¿no son semánticamente equivalentes? ¿Acaso no los usamos indistintamente para referirnos a vulnerabilidades, ataques DDoS y el exploit de día cero más reciente?

Puede que sí, pero los profesionales de la seguridad suelen ser mucho más precisos, sobre todo porque, de no serlo, sus presupuestos superarían los de todo el departamento de TI mientras libran una guerra digital contra el creciente arsenal de herramientas, técnicas y tecnologías utilizadas para burlar sus defensas. Esto se debe a que no todas las amenazas entrañan el mismo riesgo.

El riesgo es una medida calculada en la que intervienen diversos factores, como la probabilidad de que se produzca un suceso y el impacto que tendría si se materializara. Todos sabemos que hoy mismo podría atropellarnos un autobús mientras cruzamos la calle y que las consecuencias serían nefastas, pero la probabilidad de que eso ocurra es tan baja que la mayoría lo consideramos un riesgo muy reducido (si es que llega a registrarse en nuestra escala de riesgos). En cambio, llevar tacones de tres pulgadas con la suela lisa en pleno invierno de Wisconsin conlleva una alta probabilidad de sufrir una caída con consecuencias desfavorables, por lo que personalmente considero que supone un riesgo bastante elevado durante los meses de invierno.

Eso es el riesgo.

Las amenazas son otra cosa. Algo que no podemos controlar, como el tiempo, las rutas de autobús o la decisión de un atacante de lanzar hoy un ataque volumétrico contra nuestro sitio web.

Uno de los objetivos de los profesionales de la seguridad y de sus organizaciones es minimizar el riesgo mitigando las amenazas y reduciendo la probabilidad de que se produzca un ataque. Si estamos a 20 grados bajo cero y el camino de entrada está cubierto de hielo, me pongo unas botas planas con suelas de buen agarre. La amenaza se mitiga (aunque no se elimina) y, por tanto, se reduce el riesgo. Si de repente se descubre una nueva vulnerabilidad, tengo que determinar qué riesgo supone esa nueva amenaza para mi organización.

De hecho, esta metodología de evaluación de riesgos está tan aceptada que el sector la describe matemáticamente:

A(ctivo) + V(ulnerabilidad) + A(menaza) = R(iesgo)

Esto permite a cada organización no solo ponderar los distintos factores en función de sus necesidades empresariales y su tolerancia al riesgo, sino también actuar de forma coherente. Así se pueden evitar reacciones precipitadas y motivadas por el pánico cuando se anuncian nuevas vulnerabilidades, especialmente si el riesgo evaluado resulta estar dentro de los niveles de tolerancia de la organización.

Entonces, ¿qué pasa con HEIST?

Lo que nos lleva a HEIST, siglas de «HTTP Encrypted Information can be Stolen through TCP-Windows» (la información cifrada mediante HTTP puede ser robada a través de las ventanas TCP). Obviamente, HEIST es mucho más fácil de decir y suena muy al estilo de Misión Imposible, ¿verdad? Esta vulnerabilidad se presentó en BlackHat y ya está circulando por Internet en artículos de Ars Technica y Engadget. Hasta ahora, no se ha detectado ningún caso real. No es una vulnerabilidad fácil de aprovechar, y los investigadores —incluidos los nuestros— señalan que explotar HEIST no es una tarea trivial. Se trata de un complejo ataque de canal lateral que combina el comportamiento de las API del navegador (observa el funcionamiento habitual de TCP mediante una API del navegador capaz de medir los tiempos de respuesta), el comportamiento de las aplicaciones web, la compresión de contenido, TCP y la criptografía.

Este ataque podría generar mucho tráfico de red si fuera necesario completar varias solicitudes, aunque encaja mejor en la categoría de «ruidoso». Ninguna de estas características resulta atractiva para los ciberdelincuentes que no quieren llamar la atención. Aun así, si se explotara con éxito, los atacantes podrían combinarlo con BREACH o CRIME para descifrar cargas útiles y llevarse el proverbial premio gordo digital, dejando al descubierto datos personales y empresariales sensibles (quizá críticos). En ese caso, probablemente no les importaría cuánto ruido generasen si consiguieran obtener información de identificación personal (PII): el premio gordo digital.

Esto es una amenaza. Podría utilizarse para extraer datos. Eso se denomina una filtración de datos y es Algo Muy Malo™. La pregunta es: ¿cuándo se convierte esta amenaza en un riesgo real?

Bueno, hoy (en el momento de escribir esto, para ser exactos), esta amenaza no era real. Es decir, no se había detectado en casos reales. Pero eso no significa que no exista en la práctica, sino simplemente que aún no se ha detectado. Todavía. A día de hoy. Ahora mismo.

¿Te da vueltas la cabeza? Ahora ya sabes por qué los profesionales de la seguridad siempre parecen tener la mirada perdida. Porque tienen que gestionar constantemente este tipo de procesos mentales y de toma de decisiones.

Así pues, la pregunta es: si esta amenaza llega a ser existencial, ¿cuál es el riesgo? Para responder, hay que determinar cuál sería el impacto si se explotara la vulnerabilidad. Si alguien consigue extraer datos de tu aplicación o de tu sitio web, ¿qué consecuencias tendría? ¿Cuál sería el coste? No olvides incluir el impacto en la marca, ya que forma parte de esta ecuación, cada vez más compleja. También hay que tener en cuenta el coste de mitigar la amenaza. La ecuación cambia cuando dicho coste es elevado frente a una solución de impacto relativamente bajo. Si tienes que intervenir en todos los servidores web del centro de datos —y de la nube— para modificar un único ajuste con el fin de mitigar la amenaza, eso supone mucho tiempo y, por consiguiente, dinero para algo que podría llegar a representar una amenaza existencial. Si el riesgo es bajo, probablemente adoptarías una comprensible actitud de «esperar y ver» en lugar de precipitarte porque alguien haya dado la voz de alarma.

Si la mitigación tiene un impacto relativamente bajo en cuanto a los costes de implementación —por ejemplo, un sencillo script que confunda al atacante variando el tamaño de los datos devueltos y dificulte así la ejecución de HEIST—, podría plantearse seguir adelante e implementarla. Al fin y al cabo, el coste de reducir aún más el riesgo sería mínimo y, casi con toda seguridad, muy inferior a las consecuencias de que dicho ataque HEIST se lleve a cabo en el futuro.

Un ejercicio constante de (re)equilibrio

La realidad es que la seguridad supone una lucha constante por minimizar el riesgo mitigando las amenazas, al tiempo que se navega por el campo de minas político que constituyen la mayoría de las organizaciones de TI. Con demasiada frecuencia, los profesionales de la seguridad deciden que no merece la pena esforzarse en implementar ni siquiera medidas sencillas de mitigación para amenazas cuya probabilidad de riesgo fluctúa, porque las TI están organizadas en silos funcionales.

Esperan hasta que el riesgo aumenta y obliga a reaccionar, en lugar de mitigar la amenaza de forma proactiva. Por ejemplo, muchos de los exploits que más han dado que hablar en los últimos dos años se centraban en las aplicaciones. Para mitigarlos, es necesario desplegar soluciones en la ruta de datos, antes de que el tráfico llegue a la aplicación, ya que el lugar más eficiente y eficaz para hacerlo sigue siendo el punto en el que las aplicaciones se agrupan finalmente para su escalado y distribución. Sin embargo, ese punto de control estratégico lo gestionan los equipos de entrega de aplicaciones, no los de seguridad. El esfuerzo necesario para mitigar estas amenazas desde el principio supera el riesgo. Dado que la capacidad de ambos grupos para encontrarse a medio camino, por así decirlo, sigue siendo un reto constante para las organizaciones, la reducción proactiva de los riesgos y la mitigación de las amenazas en la capa de aplicación sencillamente no se llevan a cabo.

En estos momentos, es probable que la mayoría de las organizaciones considere que HEIST entraña un riesgo bajo. Pero no nos engañemos: es una amenaza y, por tanto, merece que la tengamos en cuenta ahora que todos hemos sido advertidos de su existencia, antes de que se ponga en práctica. Es necesaria la coordinación entre equipos para poder implantar soluciones de seguridad «sin servidor», como esta medida de mitigación para HEIST, antes de que la amenaza se vuelva existencial y el riesgo de explotación desate una vorágine de costosas actividades e implementaciones para hacerle frente.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie