Una versión de este artículo apareció en Revista SC. Se ha modificado y distribuido aquí.
Si alguna vez han asaltado su casa por ladrones, comprenderá esa sensación inicial de hundimiento de que algo anda mal, seguida de darse cuenta de que, de hecho, le han robado y violado. Por lo general, esto se traduce en un malestar duradero, por no hablar de la adopción de medidas de seguridad similares a las de Fort Knox.
Ahora imagine que su casa es asaltada porque los ladrones se han hecho una llave. Se arrastran de un lado a otro, yendo y viniendo a su antojo, pero tienen cuidado de no ser detectados. Entonces, un día, te das cuenta demasiado tarde de que las joyas que escondiste en el congelador han desaparecido, que tu caja fuerte está vacía y que tus pertenencias personales han sido saqueadas. Esta es la misma realidad 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 filtraciones de datos exitosas fueron el resultado de exploits de día cero y, lamentablemente, la mayoría de las empresas siguen estando mal preparadas para mejorar significativamente esta estadística.
Los ataques de día cero, por definición, no dan tiempo a los desarrolladores para encontrar y corregir las vulnerabilidades existentes que podrían explotarse, porque el actor de la amenaza fue el primero en entrar. El daño ya está hecho y, a continuación, se pone manos a la obra para arreglar el daño causado tanto al software como a la reputación de la empresa. Los atacantes siempre tienen una ventaja, y cerrar esa ventaja en la medida de lo posible es crucial.
El regalo navideño que nadie quería, Log4Shell, está haciendo estallar Internet actualmente, y se dice que más de mil millones de dispositivos se ven afectados por esta catastrófica vulnerabilidad de Java. Se perfila como el peor ataque que se haya registrado en un solo día, y solo acabamos de empezar. A pesar de algunos informes que afirman que los exploits comenzaron unos días antes de su divulgación pública, una presentación realizada en la Black Hat Conference en 2016 sugeriría que este es un problema conocido desde hace algún tiempo. Ay. Peor aún, es tremendamente fácil de explotar, y todos los guionistas y actores de amenazas del planeta buscan dinero con esta vulnerabilidad.
Entonces, ¿cuál es la mejor manera de defenderse de una amenaza siniestra y resbaladiza, sin mencionar las vulnerabilidades que se han pasado por alto en el proceso de desarrollo de software? Vamos a echar un vistazo.
Los ataques de día cero contra objetivos importantes son poco frecuentes (y costosos).
Hay un enorme mercado de exploits en la web oscura, y los días cero suelen costar un dineral, por ejemplo en este artículo cotizaba en 2,5 millones de dólares en el momento de escribir este artículo. Se dice que es una vulnerabilidad del sistema iOS de Apple, por lo que no sorprende que el investigador de seguridad esté por las nubes; al fin y al cabo, esto podría ser la puerta de entrada para comprometer millones de dispositivos, recopilar miles de millones de registros de datos confidenciales y hacerlo el mayor tiempo posible antes de que se descubran y se corrijan.
Pero, ¿quién tiene esa cantidad de dinero, de todos modos? Por lo general, los sindicatos organizados de ciberdelincuencia se llevan el dinero si lo consideran digno, especialmente para los ataques de ransomware, que son cada vez más populares. Sin embargo, los gobiernos y los departamentos de defensa de todo el mundo se encuentran entre la clientela de los exploits que pueden utilizar para obtener información sobre amenazas y, en escenarios más positivos, las propias empresas pueden comprar sus propias vulnerabilidades potenciales de día cero para poder mitigar los desastres.
En 2021 se batieron récords para descubrir exploits en tiempo real desde cero, y son las grandes organizaciones, los departamentos gubernamentales y la infraestructura los que corren mayor riesgo de ser investigados para detectar cualquier punto débil. No hay forma de estar completamente a salvo de la posibilidad de un ataque de día cero, pero se puede «jugar» de alguna manera ofreciendo un programa de recompensas por errores generoso y bien estructurado. En lugar de esperar a que alguien te dé las llaves de tu castillo de software en un mercado de la dark web, busca mejoras de seguridad legítimas y ofréceles recompensas decentes por la divulgación ética y las posibles soluciones.
Y si resulta que se trata de una espeluznante amenaza de día cero, no cabe duda de que tendrás que gastar más que una tarjeta de regalo de Amazon (y valdrá la pena hacerlo).
Sus herramientas podrían ser una responsabilidad para su personal de seguridad.
Las engorrosas herramientas de seguridad han sido un problema durante mucho tiempo, y el CISO promedio administra entre 55 y 75 herramientas en su arsenal de seguridad. Además de ser la navaja suiza más confusa (metafórica) del mundo, el 53 % de las empresas ni siquiera están seguras de que están trabajando de manera eficaz, según un estudio del Instituto Ponemon. Otro estudio reveló que solo el 17 % de los CISO pensaba que su sistema de seguridad era «completamente efectivo».
En un campo conocido por su agotamiento, la falta de personas capacitadas 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 monitoreo de enormes conjuntos de herramientas es una carga. Este es exactamente el tipo de escenario que puede hacer que pierdan una alerta crítica, lo que bien podría haber sido el caso cuando se trataba de evaluar adecuadamente los puntos débiles de Log4j.
La seguridad preventiva debe incluir modelos de amenazas impulsados por los desarrolladores.
Los desarrolladores suelen introducir vulnerabilidades a nivel de código, y necesitan orientación precisa y vías de aprendizaje regulares para desarrollar habilidades de codificación seguras. Sin embargo, los desarrolladores de sistemas seguros avanzados 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 sorprendernos que las personas que mejor conocen su software sean los desarrolladores que se han sentado ahí y lo han creado. Tienen un profundo conocimiento sobre cómo los usuarios interactúan con él, dónde se utilizan las funciones y, cuando son suficientemente conscientes de la seguridad, sobre los posibles escenarios en los que podría fallar o ser explotado.
Si volvemos a referirnos al exploit de Log4Shell, lamentablemente nos encontramos ante una situación en la que los expertos y conjuntos de herramientas complejos no han podido detectar una vulnerabilidad catastrófica; sin embargo, es posible que no se haya producido en absoluto si la biblioteca se configuró para desinfectar las entradas de los usuarios. La decisión de no hacerlo parece haber sido una característica poco conocida para mayor comodidad, pero hizo que fuera tremendamente fácil de explotar (piense en el nivel de inyección de SQL, ciertamente no en cosas geniales). Si el modelado de amenazas lo hubiera realizado un grupo de desarrolladores entusiastas y expertos en seguridad, es muy probable que este escenario se hubiera teorizado y considerado.
Un buen programa de seguridad tiene un componente emocional, en el que la intervención y los matices humanos son fundamentales para resolver los problemas creados por el hombre. La modelización de amenazas requiere empatía y experiencia para ser eficaz, al igual que la codificación y la configuración seguras a nivel arquitectónico del software y las aplicaciones. No es algo a lo que los desarrolladores deban lanzarse de la noche a la mañana, pero lo ideal es encontrar un camino claro para mejorar sus habilidades hasta un nivel en el que puedan aliviar la presión del equipo de seguridad para realizar esta importante tarea (y es una excelente manera de establecer una buena relación entre ambos equipos).
Los días cero conducen a n días.
La siguiente parte para hacer frente a un día cero consiste en lanzar 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. Con Log4Shell, podría eclipsar a Heartbleed en su resistencia y potencia ante el hecho de que está integrado en millones de dispositivos y crea dependencias complejas en una compilación de software.
Siendo realistas, no hay forma de detener por completo este tipo de ataque insidioso. Sin embargo, si nos comprometemos a utilizar todas las vías posibles para crear un software seguro y de calidad, y a abordar el desarrollo con la misma mentalidad que con la infraestructura crítica, todos podemos tener posibilidades de luchar.
