Una versión de este artículo ha sido publicada en Revue SC. Ha sido modificado y difundido aquí.
Si alguna vez ha sufrido un robo en su casa, comprenderá esa sensación inicial de que algo no va bien, seguida de la constatación de que efectivamente le han robado y violado. Esto suele provocar una incomodidad duradera, por no hablar de la necesidad de adoptar medidas de seguridad comparables a las de Fort Knox.
Imagina ahora que te roban en tu casa porque los ladrones han hecho una copia de la llave. Entran y salen a su antojo, pero tienen cuidado de no ser detectados. Entonces, un día, te das cuenta demasiado tarde de que las joyas que habías escondido en el congelador han desaparecido, que tu caja fuerte ha sido vaciada y que tus efectos personales han sido destrozados. Esta es la misma realidad a la que se enfrenta una organización si es víctima de un ciberataque de tipo «día cero». En 2020, un estudio del Ponemon Institute reveló que el 80 % de las violaciones de datos exitosas eran el resultado de exploits de día cero y, lamentablemente, la mayoría de las empresas aún no están preparadas para mejorar significativamente esta estadística.
Los ataques «día cero», por definición, no dan tiempo a los desarrolladores para detectar y corregir las vulnerabilidades existentes que podrían ser explotadas, ya que es el autor de la amenaza quien ha actuado primero. El daño ya está hecho y entonces comienza una carrera frenética para reparar tanto el software como el daño a la reputación de la empresa. Los atacantes siempre tienen ventaja, y es fundamental reducir esa ventaja en la medida de lo posible.
El regalo de Navidad que nadie quería, Log4Shell, está revolucionando Internet, con más de mil millones de dispositivos afectados por esta catastrófica vulnerabilidad de Java. Se perfila como el peor ataque de día cero jamás registrado, y esto no ha hecho más que empezar. A pesar de que algunos informes indican 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 sugiere que este problema se conoce desde hace tiempo. Ay. Peor aún, es extremadamente fácil de explotar, y todos los guionistas y actores de amenazas del planeta están buscando sacar provecho de esta vulnerabilidad.
¿Cuál es entonces la mejor manera de defenderse contra una amenaza siniestra y escurridiza, por no hablar de las vulnerabilidades que no se han detectado durante el proceso de desarrollo de software? Echemos un vistazo.
Los ataques «día cero» contra objetivos importantes son poco frecuentes (y costosos).
Existe un enorme mercado para los exploits en la Dark Web, y los días cero tienden a ser caros, por citar solo un ejemplo en este artículo cotizado en 2,5 millones de dólares en el momento de redactarlo. Señalado como un exploit de Apple iOS, no es de extrañar que el precio que pide el investigador de seguridad sea exorbitante. Al fin y al cabo, podría tratarse de una puerta de entrada para comprometer millones de dispositivos, recopilar miles de millones de datos confidenciales y hacerlo durante el mayor tiempo posible antes de que se descubra y se corrija.
Pero, ¿quién tiene tanto dinero, de todos modos? En general, las organizaciones criminales cibernéticas encuentran el dinero si lo consideran útil, especialmente para los ataques de ransomware, cada vez más populares. Sin embargo, los gobiernos mundiales y los departamentos de defensa forman parte de la clientela de los exploits que pueden utilizar con fines de inteligencia sobre amenazas y, en escenarios más positivos, las propias empresas pueden comprar sus propios exploits potenciales de día cero para poder mitigar las catástrofes.
El año 2021 ha batido récords en cuanto al descubrimiento de vulnerabilidades de día cero en tiempo real, y son las grandes organizaciones, los servicios gubernamentales y las infraestructuras los que corren mayor riesgo de ser sondeados para detectar posibles debilidades. No hay forma de estar totalmente a salvo de un ataque de día cero, pero se puede «jugar un poco» ofreciendo un programa de recompensas por errores generoso y bien estructurado. En lugar de esperar a que alguien le ofrezca las claves de su castillo de software en un mercado de la web oscura, recurra a profesionales de la seguridad legítimos y ofrézcales recompensas decentes en caso de divulgación ética y posibles correcciones.
Y si resulta ser una amenaza del día cero impresionante, es de suponer que necesitarás algo más que una tarjeta regalo de Amazon (y valdrá la pena).
Su equipamiento podría suponer un obstáculo para su personal de seguridad.
La pesadez de las herramientas de seguridad es un problema desde hace mucho tiempo, ya que el CISO medio gestiona entre 55 y 75 herramientas en su arsenal de seguridad. Además 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 manera eficaz, según un estudio del Ponemon Institute. Otro estudio reveló que solo el 17 % de los RSSI consideraban que su solución de seguridad era «totalmente eficaz».
En un ámbito conocido por su agotamiento profesional, su falta de personal cualificado en materia de seguridad para responder a la demanda y su 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 resulta tedioso. Este es precisamente el tipo de situación que puede hacer que pasen por alto una alerta crítica, como puede haber sido el caso a la hora de evaluar correctamente las vulnerabilidades de Log4j.
La seguridad preventiva debe incluir un modelo de amenazas dirigido por los desarrolladores.
Las vulnerabilidades en el código suelen ser introducidas por los desarrolladores, que necesitan asesoramiento específico y formación continua para desarrollar habilidades de codificación seguras. Sin embargo, los desarrolladores seguros de alto nivel han tenido la oportunidad de aprender y practicar el modelado de amenazas como parte de su proceso de creación de software.
No es de extrañar que las personas que mejor conocen su software sean los desarrolladores que lo han creado. Tienen un profundo conocimiento de cómo interactúan los usuarios con él, dónde se utilizan las funciones y, cuando son lo suficientemente conscientes de la seguridad, de los posibles escenarios en los que podría romperse o explotarse.
Si lo relacionamos con el exploit Log4Shell, lamentablemente nos encontramos ante un escenario en el que una vulnerabilidad catastrófica ha escapado a la detección de expertos y conjuntos de herramientas complejas, pero que quizá no habría ocurrido en absoluto si la biblioteca se hubiera configurado para limpiar las entradas de los usuarios. La decisión de no hacerlo parece haber sido una característica oscura por comodidad, pero la hizo extremadamente fácil de explotar (pensemos en el nivel de inyección SQL, que ciertamente no es genial). Si el modelado de amenazas hubiera sido realizado por un grupo de desarrolladores apasionados y expertos en seguridad, es muy probable que este escenario se hubiera teorizado y contemplado.
Un buen programa de seguridad incluye un componente emocional, ya que la intervención humana y los matices son fundamentales para resolver los problemas creados por el hombre. 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 la arquitectura del software y las aplicaciones. Los desarrolladores no deberían enfrentarse a esta tarea de la noche a la mañana, pero lo ideal es encontrar una vía clara para mejorarlos hasta un nivel que les permita aliviar la presión sobre el equipo de seguridad en esta importante tarea (y es una forma excelente de establecer relaciones entre ambos equipos).
Un día cero conduce a n días.
El siguiente paso para hacer frente a un día cero consiste en publicar los parches lo más rápido posible, con la esperanza de que cada usuario del software vulnerable los aplique lo antes posible, y sin duda antes de que un atacante llegue primero. Con Log4Shell, podría eclipsar a Heartbleed en cuanto a su resistencia y potencia, dada su integración en millones de dispositivos y la creación de dependencias complejas dentro del diseño del software.
En realidad, no hay forma de detener por completo este tipo de ataques insidiosos. Sin embargo, si nos comprometemos a utilizar todos los medios a nuestro alcance para crear software seguro y de calidad, y abordamos el desarrollo con la misma mentalidad que si se tratara de una infraestructura crítica, todos tendremos la oportunidad de lograrlo.
