¿Es HEIST un riesgo o una amenaza?

Los profesionales de seguridad tienen la tarea de comprender la diferencia entre riesgos y amenazas y actuar en consecuencia. Para el profano en la materia (es decir, la mayoría de nosotros), la diferencia entre ambos puede parecer inexistente. Después de todo, ¿no son semánticamente equivalentes? ¿No los usamos indistintamente para describir vulnerabilidades, ataques DDoS y el último exploit de día cero?

Quizás sí, pero los profesionales de seguridad suelen ser mucho más precisos que eso, principalmente porque si no lo fueran, sus presupuestos superarían a todo el departamento de TI mientras libraban una guerra digital contra la creciente acumulación de herramientas, técnicas y tecnología utilizadas para derrotar sus defensas. Esto se debe a que no todas las amenazas conllevan el mismo riesgo.

El riesgo es una medida calculada que involucra una serie de factores, incluida la probabilidad de ocurrencia y el impacto si se explota. Todos sabemos que hoy podríamos ser atropellados por un autobús y sufrir graves consecuencias al cruzar la calle, pero la probabilidad de que eso ocurra es tan baja que la mayoría de nosotros lo consideramos un riesgo muy bajo (si es que lo registramos en nuestro medidor de riesgos). Por el contrario, llevar tacones de tres pulgadas sin dibujo en medio del invierno de Wisconsin tiene una alta probabilidad de producirse una caída con consecuencias desfavorables, por lo que personalmente considero que es un riesgo bastante alto en los meses de invierno.

Eso es riesgo.

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

Uno de los objetivos de los profesionales de seguridad y sus organizaciones es minimizar el riesgo mitigando las amenazas y reduciendo la probabilidad de una explotación. Si hace 20 grados bajo cero y la entrada está cubierta de hielo, uso botas planas con buena suela. La amenaza se mitiga (pero no se elimina) y, por tanto, se reduce el riesgo.  Si de repente se descubre una nueva vulnerabilidad, tengo que decidir qué riesgo representa esa nueva amenaza para mi organización.

De hecho, esta es una metodología tan aceptada para evaluar el riesgo que la industria la describe matemáticamente:

A(activo) + V(ulnerabilidad) + T(amenaza) = R(riesgo)

Esto permite a las organizaciones individuales no sólo ponderar los factores individuales según sus requisitos comerciales y su tolerancia al riesgo, sino también actuar de manera consistente. Esto puede evitar reacciones de pánico e impulsivas cuando se anuncian nuevas vulnerabilidades, en particular si el riesgo evaluado resulta estar por debajo de las tolerancias organizacionales.

¿Y qué pasa con HEIST?

Lo que nos lleva a HEIST, que significa HTTP La información cifrada puede ser robada a través de TCP-Windows. HEIST es obviamente mucho más fácil de decir y suena como Misión Imposible, ¿no? Esta vulnerabilidad fue presentada en BlackHat y ahora mismo está circulando por Internet en artículos en Ars Technica y Engadget . Hasta el momento no ha sido avistado en estado salvaje. No es una vulnerabilidad fácil de explotar y los investigadores (incluidos los nuestros) señalan que no es una tarea trivial explotar HEIST. Es un ataque de canal lateral complejo que combina el comportamiento de la API del navegador (observa la forma en que TCP normalmente funciona con una API del navegador que puede cronometrar las respuestas), el comportamiento de la aplicação web, la compresión de contenido, TCP y criptografía.

Este ataque podría afectar a toda la red si es necesario completar varias solicitudes, pero es más adecuado en la categoría "ruidoso". Ambos son poco atractivos para los malos actores que no quieren hacerse notar. Y, sin embargo, si se explota con éxito, los atacantes podrían combinarlo con BREACH o CRIME para descifrar las cargas útiles y ganar el premio mayor digital, exponiendo datos personales y comerciales confidenciales (quizás críticos). En ese caso, probablemente no les importaría lo ruidosos que fueran si tuvieran éxito en obtener información de identificación personal (PII), el premio mayor digital.

Esto es una amenaza. Podría usarse para exfiltrar datos. Eso se llama violación y es algo muy malo™. La pregunta es ¿cuándo esta amenaza se convierte en un riesgo real?

Bueno, hoy (cuando escribí esto, para ser preciso), esta amenaza no era existencial. Es decir, no había sido visto en estado salvaje. Pero eso no significa que no esté en estado salvaje, sólo significa que no se ha visto en estado salvaje. Todavía. Hoy. Ahora mismo.

¿Ya te da vueltas la cabeza? Ahora sabes por qué los profesionales de seguridad siempre parecen tener una mirada aturdida en sus caras. Porque tienen que gestionar este tipo de proceso de pensamiento y toma de decisiones todo el tiempo. 

La pregunta entonces es: ¿cuál es el riesgo si esta amenaza se vuelve existencial? Para responder a esta pregunta hay que determinar cuál sería el impacto si se explotara la vulnerabilidad. Si alguien logra extraer datos de tu aplicación o de tu sitio, ¿cuál es el impacto? ¿Cual será su costo? No olvides incluir el impacto de la marca, eso es parte de la ecuación (cada vez más compleja). También lo es el costo de la mitigación. La ecuación cambia cuando el costo de la mitigación es alto en comparación con una solución de impacto relativamente bajo. Si es necesario tocar todos los servidores web en el centro de datos (y en la nube) para modificar solo una configuración para mitigar la amenaza, eso es mucho tiempo (y, por consiguiente, dinero) para algo que podría ser existencialmente amenazante. Si el riesgo es bajo, probablemente adoptarías una actitud comprensible de “esperar y ver” en lugar de apresurarte porque el niño gritó “¡lobo!”.

Si la mitigación tiene un impacto relativamente bajo en términos de costos de implementación, digamos un script simple que confunde al atacante al variar el tamaño de los datos devueltos y, por lo tanto, hace que HEIST sea más difícil de llevar a cabo, podría considerar seguir adelante e implementarlo. Después de todo, el coste de reducir aún más el riesgo fue mínimo, y es casi seguro que es mucho menor que las consecuencias si dicho robo se lleva a cabo en el futuro.

Un acto de (re)equilibrio constante

La realidad es que la seguridad es una batalla constante para minimizar el riesgo mitigando las amenazas mientras se avanza por el campo minado político que son la mayoría de las organizaciones de TI. Con demasiada frecuencia, los profesionales de seguridad deciden no intentar implementar ni siquiera mitigaciones simples para amenazas con probabilidad de riesgo fluctuante porque la TI existe en silos de funcionalidad.

Esperan hasta que el riesgo aumenta y fuerza una reacción, en lugar de mitigar proactivamente la amenaza. Por ejemplo, muchos de los exploits más comentados de los últimos dos años estaban centrados en aplicação . Para mitigarlos, es necesario implementar soluciones en la ruta de datos, antes de la aplicação, porque la ubicación más eficiente y efectiva para hacerlo sigue siendo el punto en el que las aplicações finalmente se agregan para escalar y entregar. Pero ese punto estratégico de control lo gestionan los equipos de distribución de aplicação , no los equipos de seguridad. El esfuerzo necesario para mitigar tales amenazas desde el principio supera el riesgo. Dado que la capacidad de los dos grupos para encontrarse en el medio, por así decirlo, sigue siendo un desafío constante para las organizaciones, reducir los riesgos y mitigar las amenazas de manera proactiva en la capa de aplicação simplemente no sucede.

En la actualidad, es probable que HEIST se considere un riesgo bajo para la mayoría de las organizaciones. Pero no nos equivoquemos: es una amenaza y, por lo tanto, merece ser considerada ahora, cuando todos hemos sido advertidos sobre su existencia antes de que se ponga en juego. Se requiere coordinación cruzada para que las soluciones de seguridad “sin servidor”, como esta mitigación para HEIST, se puedan implementar antes de que la amenaza se vuelva existencial y el riesgo de explotación lleve a todos a un frenesí de actividades e implementaciones costosas para abordarla.