Los ataques de día cero van en aumento. Es hora de planificar una ventaja defensiva.

Una versión de este artículo apareció en Revista SC. Se ha modificado y sindicado aquí.
Si

alguna vez ha sufrido un robo en su casa, entenderá esa sensación inicial de que algo va mal, seguida de la constatación de que, efectivamente, le han robado y violado. El resultado suele ser un malestar duradero, por no hablar de un giro hacia medidas de seguridad que rivalizarían con Fort Knox.

Ahora imagina que tu casa es asaltada, porque los ladrones se han hecho con una llave. Se mueven sigilosamente, entrando y saliendo a su antojo, pero tienen cuidado de no ser detectados. Entonces, un día, te das cuenta demasiado tarde de que las joyas que escondías en el congelador han desaparecido, tu caja fuerte ha sido vaciada y tus pertenencias personales han sido saqueadas. Esta es la realidad equivalente a la que se enfrenta una organización si es víctima de un ciberataque de día cero. En 2020, un estudio del Instituto Ponemon reveló que el 80% de las violaciones de datos que tuvieron éxito fueron el resultado de explotaciones de día cero, y lamentablemente, la mayoría de las empresas siguen estando mal equipadas para mejorar significativamente esta estadística.

Los ataques de día cero, por definición, dan a los desarrolladores cero tiempo para encontrar y parchear las vulnerabilidades existentes que podrían ser explotadas, porque el actor de la amenaza llegó primero. El daño está hecho y luego es una carrera loca para arreglar tanto el software como el daño a la reputación de la empresa. Los atacantes siempre están en ventaja, y es crucial cerrar esa ventaja en la medida de lo posible. 

El regalo navideño que nadie quería -Log4Shell- está haciendo estallar Internet, con más de mil millones de dispositivos afectados por esta catastrófica vulnerabilidad de Java. Se está convirtiendo en el peor ataque 0day registrado, y sólo estamos empezando. A pesar de que algunos informes afirman que los exploits comenzaron unos días antes de la divulgación pública, una presentación dada en la Conferencia Black Hat en 2016 sugeriría que este ha sido un problema conocido durante algún tiempo. Ouch. Peor aún, es dolorosamente fácil de explotar, y cada script kiddie y actor de amenaza en el planeta está persiguiendo el pago con esta vulnerabilidad.

Entonces, ¿cuál es el mejor camino para defenderse de una amenaza escurridiza y siniestra, por no hablar de las vulnerabilidades que se han pasado por alto en el proceso de desarrollo del software? Echemos un vistazo. 

Los ataques de día cero contra grandes objetivos son raros (y caros)

Hay un gran mercado para los exploits en la web oscura, y los zero-days tienden a alcanzar un precio bastante alto, con un ejemplo en este artículo que se cotiza en 2,5 millones de dólares en el momento de escribir este artículo. Al tratarse de un exploit de Apple iOS, no es de extrañar que el precio que pide el investigador de seguridad esté por las nubes; después de todo, podría ser la puerta de entrada para comprometer millones de dispositivos, recoger miles de millones de registros de datos sensibles y hacerlo lo más posible antes de que sea descubierto y parcheado.

Pero, ¿quién tiene esa cantidad de dinero? Normalmente, los sindicatos de ciberdelincuentes organizados aportarán el dinero si se considera que merece la pena, especialmente para los siempre populares ataques de ransomware. Sin embargo, los gobiernos y los departamentos de defensa de todo el mundo se encuentran entre la clientela de exploits que pueden utilizar para la inteligencia de amenazas, y en escenarios más positivos, las propias empresas pueden ser compradores de sus propios exploits potenciales de día cero para poder mitigar el desastre. 

En2021 se batieron récords de descubrimientos de exploits de día cero en vivo, y son las grandes organizaciones, los departamentos gubernamentales y las infraestructuras los que corren más riesgo de ser sondeados en busca de alguna debilidad. No hay manera de estar completamente a salvo de la posibilidad de un ataque de día cero, pero se puede "jugar el juego" de alguna manera ofreciendo un programa de recompensas por errores generoso y bien estructurado. En lugar de esperar a que alguien ofrezca las claves de tu castillo de software en un mercado de la web oscura, pon a los aficionados a la seguridad legítimos de tu parte y ofréceles recompensas decentes por la divulgación ética y las posibles correcciones.

Y si resulta ser una espeluznante amenaza de día cero, es seguro que tendrá que soltar algo más que una tarjeta de regalo de Amazon (y valdrá la pena hacerlo).

Sus herramientas podrían ser un lastre para su personal de seguridad

Las engorrosas herramientas de seguridad han sido un problema durante mucho tiempo, ya que el CISO medio maneja entre 55 y 75 herramientas en su arsenal de seguridad. Además de ser la navaja suiza (metafórica) más confusa del mundo, el 53% de las empresas ni siquiera confían en que funcionen con eficacia, según un estudio del Ponemon Institute. Otro estudio reveló que sólo el 17% de los CISOs pensaban que su pila de seguridad era "completamente efectiva".

En un campo conocido por su agotamiento, la falta de personal cualificado en seguridad para satisfacer la demanda y la necesidad de agilidad, obligar a los profesionales de la seguridad a trabajar con una sobrecarga de información en forma de datos, informes y supervisión de enormes conjuntos de herramientas es una carga. Este es exactamente el tipo de escenario que puede hacerles pasar por alto una alerta crítica, lo que bien puede haber sido el caso a la hora de evaluar adecuadamente las debilidades de Log4j. 

La seguridad preventiva debe incluir el modelado de amenazas impulsado por los desarrolladores

Las vulnerabilidades a nivel de código suelen ser introducidas por los desarrolladores, que necesitan una guía precisa y vías de aprendizaje regulares para crear habilidades de codificación segura. Sin embargo, los desarrolladores seguros del siguiente nivel han tenido la oportunidad de aprender y practicar el modelado de amenazas como parte de su proceso de creación de software.

No debería sorprender que las personas que mejor conocen su software sean los desarrolladores que lo han creado. Tienen un gran conocimiento de cómo los usuarios interactúan con él, de dónde se utilizan las funciones y, si son lo suficientemente conscientes de la seguridad, de los posibles escenarios en los que podría romperse o ser explotado.

Si volvemos al exploit Log4Shell, lamentablemente estamos viendo un escenario en el que una vulnerabilidad catastrófica ha escapado a la detección por parte de expertos y complejos conjuntos de herramientas, sin embargo, podría no haber ocurrido en absoluto si la biblioteca estaba configurada para sanear la entrada del usuario. La decisión de no hacerlo parece haber sido una característica oscura para mayor comodidad, pero hizo que fuera dolorosamente fácil de explotar (piense en el nivel de inyección SQL, ciertamente no es algo genial). Si un grupo de desarrolladores expertos en seguridad hubiera realizado un modelo de amenazas, es muy probable que este escenario hubiera sido teorizado y considerado.

Un gran programa de seguridad tiene un componente emocional, con la intervención humana y los matices en el centro de la solución de los problemas creados por el ser humano. El modelado de amenazas requiere empatía y experiencia para ser eficaz, al igual que la codificación y la configuración seguras a nivel de arquitectura del software y las aplicaciones. No es algo a lo que los desarrolladores deban dedicarse de la noche a la mañana, pero lo ideal es que haya una vía clara para capacitarlos hasta un nivel en el que puedan aliviar la presión del equipo de seguridad en esta importante tarea (y es una forma estupenda de establecer una relación entre ambos equipos). 

Los días cero llevan a los días n

La siguiente parte de la gestión de un día cero consiste en sacar los parches lo más rápido posible, con la esperanza de que todos los usuarios del software vulnerable los apliquen lo antes posible, y desde luego antes de que un atacante llegue primero. El caso de Log4Shell podría eclipsar a Heartbleed en cuanto a su resistencia y potencia, ya que está incrustado en millones de dispositivos y crea complejas dependencias en una compilación de software.

Siendo realistas, no hay manera de detener completamente este tipo de ataque insidioso. Sin embargo, con el compromiso de utilizar todas las vías para crear un software seguro y de calidad, y abordando el desarrollo con la misma mentalidad con la que se abordan las infraestructuras críticas, todos podemos tener una oportunidad de luchar.