Detenga los ataques de día cero. Es hora de planificar una línea de defensa.

Una versión de este artículo apareció en SC Magazine. Ha sido modificado y distribuido aquí.


Si alguna vez ha sufrido un robo en su hogar, comprenderá esa sensación inicial de que algo no va bien, seguida de la constatación de que realmente le han robado y le han hecho daño. Esto se aplica a las quejas persistentes, solo para seguir con un cambio de medidas de seguridad que se llevarían a cabo con Fort Knox.

Imagina que alguien entra en tu casa porque los ladrones han hecho una copia de la llave. Se mueven sigilosamente, entran y salen a su antojo, pero se aseguran de no ser descubiertos. Entonces, un día, te das cuenta demasiado tarde de que las joyas que habías escondido en el congelador han desaparecido, tu caja fuerte ha sido vaciada y tus objetos personales han sido saqueados. Esta es la realidad equivalente, con una empresa involucrada, si ofrece ataques cibernéticos de día cero. En 2020, un estudio del Ponemon Institute reveló que el 80 % de las violaciones de privacidad exitosas fueron el resultado de exploits de día cero, y lamentablemente la mayoría de las empresas están mal equipadas para mejorar significativamente estas estadísticas.

Por definición, los ataques de día cero no dan tiempo a los desarrolladores para encontrar y corregir las vulnerabilidades existentes que podrían ser explotadas, ya que el agente malicioso ha penetrado primero. El daño ya está hecho y es enorme, tanto para el software como para la reputación de la empresa. Los atacantes siempre tienen ventaja, y es fundamental reducir esta ventaja en la medida de lo posible.

El regalo de Navidad que nadie quería — Log4Shell — está revolucionando Internet. Alrededor de mil millones de dispositivos se verán afectados por esta catastrófica vulnerabilidad de Java. Se perfila como el peor ataque de día cero de todos los tiempos, y esto solo es el principio. A pesar de algunos informes que indican que los exploits comenzaron unos días antes de su publicación, una presentación en la Black Hat Conference en 2016 sugiere que se trata de un problema conocido desde hace tiempo. Ay. Peor aún, es terriblemente fácil de explotar, y todos los script kiddies y actores maliciosos del planeta están persiguiendo esta vulnerabilidad.

Entonces, ¿cuál es la mejor manera de protegerse de una amenaza resbaladiza y oscura, por no hablar de las brechas de seguridad que se pasaron por alto en el proceso de desarrollo de software? Echemos un vistazo.

Los ataques de día cero contra objetivos importantes son poco frecuentes (y costosos).

En la Dark Web existe un enorme mercado de exploits, y los zero-days suelen costar una buena suma de dinero; por citar un ejemplo , en el momento de redactar este artículo, su precio era de 2,5 millones de dólares. Se trata de un exploit de Apple iOS, por lo que no es de extrañar que el precio que pide el investigador de seguridad se haya disparado. Al fin y al cabo, podría ser la puerta de entrada para comprometer millones de dispositivos, recopilar miles de millones de registros de datos confidenciales y hacerlo durante el mayor tiempo posible antes de que se descubra y se parchee.

Pero, ¿quién tiene tanto dinero? Por lo general, las organizaciones criminales cibernéticas organizadas solicitan el pago si lo consideran oportuno, especialmente en los populares ataques de ransomware. Sin embargo, los gobiernos y las autoridades de defensa de todo el mundo se encuentran entre los clientes de los exploits, que pueden utilizar para obtener información sobre amenazas y, en casos positivos, las propias empresas podrían ser sus potenciales exploits de día cero para evitar catástrofes.

En 2021 se batieron récords en el descubrimiento en vivo de exploits de día cero, y son las grandes organizaciones, las autoridades gubernamentales y las infraestructuras, que son las que corren mayor riesgo, las que se someten a pruebas de vulnerabilidad. No hay forma de protegerse completamente contra los ataques de día cero, pero se puede «jugar» en cierta medida ofreciendo un programa de recompensas por errores generoso y bien estructurado. En lugar de esperar a que alguien ofrezca la llave de su castillo de software en un mercado de la Dark Web, permita que los entusiastas legítimos de la seguridad accedan a su página y ofrézcales recompensas relevantes por revelaciones éticas y posibles correcciones.

Y si por casualidad se produce una amenaza de día cero, puede dar por hecho que tendrá que emitir más de una tarjeta regalo de Amazon (y merecerá la pena hacerlo).

Sus herramientas podrían suponer una carga para su personal de seguridad.

Las herramientas de seguridad estáticas son desde hace tiempo un problema, ya que el CISO medio gestiona entre 55 y 75 herramientas en su arsenal de seguridad. Aparte de ser la navaja suiza más confusa (en sentido figurado) del mundo, el 53 % de las empresas ni siquiera están convencidas de que funcionen de forma eficaz, según un estudio del Ponemon Institute. Otro estudio reveló que solo el 17 % de los CISO consideraban que su conjunto de herramientas de seguridad era «totalmente eficaz».

En un sector conocido por su agotamiento, la falta de personal especializado en seguridad para cubrir la demanda y la necesidad de agilidad, es una carga obligar a los expertos en seguridad a trabajar con el aluvión de información en forma de datos, informes y herramientas para supervisar herramientas enormes. Este es precisamente el tipo de escenario que puede llevarles a pasar por alto una alerta crítica, como ocurrió cuando se trató de examinar adecuadamente las debilidades de Log4j.

La seguridad preventiva debería incluir un modelo de amenazas orientado al desarrollador.

Los desarrolladores suelen utilizar las brechas de seguridad a nivel de código, y necesitan instrucciones precisas y un itinerario formativo regular para adquirir conocimientos de programación segura. Los desarrolladores de seguridad del siguiente nivel tienen la posibilidad de aprender y practicar en su proceso de desarrollo de software.
‍
No debería sorprender que las personas que mejor conocen su software sean los desarrolladores que lo crearon y lo desarrollaron. Tienen un profundo conocimiento de cómo los usuarios interactúan con el software, dónde se utilizan las funciones y, si son lo suficientemente conscientes de la seguridad, de los posibles escenarios en los que el software podría fallar o ser explotado.

Cuando volvemos al exploit Log4Shell, vemos un escenario en el que no se encontró una brecha de seguridad catastrófica de expertos y conjuntos de herramientas complejos. Sin embargo, es posible que no se hubieran producido en absoluto si la biblioteca se hubiera configurado para resumir las entradas de los usuarios. La decisión parece haber sido una característica oscura por razones prácticas, pero la hizo dolorosamente fácil de explotar (piensa en el nivel de inyección SQL, ciertamente nada ingenioso). Si el modelado de amenazas lo hubiera llevado a cabo un grupo de desarrolladores entusiastas y conscientes de la seguridad, es muy probable que este escenario se hubiera teorizado y puesto en práctica.

Un buen programa de seguridad tiene un componente emocional en el que la intervención humana y los matices son fundamentales para resolver los problemas causados por las personas. El modelado de amenazas requiere empatía y experiencia para ser eficaz, al igual que la codificación y configuración seguras de software y aplicaciones a nivel de arquitectura. Los desarrolladores no deben trabajar hasta altas horas de la noche, sino que lo ideal es que dejen claro que pueden delegar esta importante tarea al equipo de seguridad (y es una gran oportunidad para crear una relación entre ambos equipos).

Los días nulos dan lugar a N días.

La siguiente parte del proceso con un Zero-Day consiste en aplicar parches lo más rápido posible, con la esperanza de que cada usuario del software vulnerable lo haga lo más rápido posible y, en cualquier caso, antes que el proveedor. Log4Shell podría eclipsar a Heartbleed en cuanto a su persistencia y capacidad, dado que está integrado en millones de dispositivos y genera dependencias complejas dentro de una compilación de software.

Desde un punto de vista realista, no hay forma de detener por completo este tipo de ataques encubiertos. Sin embargo, si nos comprometemos a aprovechar todas las posibilidades para desarrollar software seguro y de alta calidad, y abordamos el desarrollo con la misma mentalidad que se emplearía en infraestructuras críticas, todos tendremos una oportunidad real.