Una versión de este artículo se publicó en Revista SC. Aquí se ha modificado y sindicado.
Si alguna vez ha sufrido un robo en su casa, comprenderá esa sensación inicial de que algo va mal. Y luego se dará cuenta de que realmente le han robado y violado su intimidad. Esto suele provocar una incomodidad duradera, por no hablar de la necesidad de adoptar medidas de seguridad comparables a las de Fort Knox.
Imagina que tu casa ha sido robada porque los ladrones se han hecho con las llaves. Se mueven libremente por todas partes, pero tienen cuidado de no ser descubiertos. Un día, desaparecen las joyas que tenías escondidas en el congelador, la caja fuerte está vacía y y se dan cuenta demasiado tarde de que han registrado minuciosamente sus pertenencias personales. Esto es lo mismo que le pasa a una organización cuando es víctima de un ataque cibernético de día cero. Según un estudio de Ponemon Institute de 2020, el 80 % de las violaciones de datos exitosas fueron el resultado de exploits de día cero y, lamentablemente, la mayoría de las empresas no están preparadas para mejorar significativamente esta estadística.
Según la definición, los ataques de día cero no dan tiempo a los desarrolladores para encontrar y corregir las vulnerabilidades existentes que pueden ser explotadas, ya que los actores maliciosos son los primeros en entrar. Una vez que se ha producido el daño, se desata una frenética carrera para reparar tanto el software como el daño a la reputación de la empresa. Dado que los atacantes siempre llevan la ventaja, es fundamental aprovechar al máximo cualquier ventaja que se pueda obtener.
Log4Shell, un regalo navideño que nadie quería, está causando furor en Internet. Se dice que más de mil millones de dispositivos se han visto afectados por esta grave vulnerabilidad de Java. Se prevé que sea el peor ataque de día cero de la historia, y esto es solo el principio. Sin embargo, algunos informes afirman que los exploits comenzaron a aparecer unos días antes de que se hicieran públicos, y una presentación realizada en la conferencia Black Hat de 2016 sugiere que se trata de un problema conocido desde hace tiempo. Para colmo, es muy fácil de explotar, y todos los script kiddies y actores maliciosos del planeta están persiguiendo a las víctimas con esta vulnerabilidad.
Entonces, sin mencionar las vulnerabilidades que se pasan por alto en el proceso de desarrollo de software, ¿cuál es la mejor manera de defenderse de amenazas resbaladizas y maliciosas? Veámoslo.
Los ataques de día cero contra objetivos de gran envergadura son poco frecuentes y muy costosos.
En la dark web existe un enorme mercado de exploits. Por poner un ejemplo, los zero-day suelen generar bastante dinero. En el momento de escribir este artículo, se cotizaba a 2,5 millones de dólares. Se sabe que se trata de un exploit para Apple iOS, por lo que no es de extrañar que el precio exigido por los investigadores de seguridad se haya disparado. Al fin y al cabo, puede ser una puerta de entrada para dañar 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 aplique un parche.
De todos modos, ¿quién tiene ese dinero? Por lo general, las organizaciones delictivas cibernéticas organizadas obtienen dinero en efectivo si consideran que algo tiene valor. Esto es especialmente cierto en el caso de los ataques de ransomware, que siempre son muy populares. Sin embargo, los gobiernos y los ministerios de defensa de todo el mundo se consideran clientes de exploits que pueden utilizarse para obtener información sobre amenazas y, en un escenario más positivo, las propias empresas pueden comprar exploits de día cero potenciales para mitigar los desastres.
En 2021 se batió el récord. En el caso de los exploits de día cero detectados en tiempo real, las organizaciones de gran tamaño, los departamentos gubernamentales y las infraestructuras son los que corren mayor riesgo de sufrir vulnerabilidades. No hay forma de estar completamente a salvo de la posibilidad de un ataque de día cero, pero ofrecer un programa de recompensas por errores generoso y sistemático permite, en cierta medida, «jugar».No espere a que alguien le proporcione la llave del castillo del software en el oscuro mercado web, sino que consiga refuerzos de seguridad legítimos y ofrezca una recompensa adecuada por la divulgación ética de información y las posibles correcciones.
Si la amenaza de un ataque de día cero es demasiado grave, es mejor asumir que tendrás que gastar más dinero que el valor de la tarjeta regalo de Amazon (y que valdrá la pena hacerlo).
El herramientas puede ser responsabilidad del responsable de seguridad.
Las engorrosas herramientas de seguridad que gestionan los CISO habituales han sido un problema desde hace mucho tiempo. Con entre 55 y 75 herramientas diferentes en su arsenal de seguridad, a excepción de la navaja suiza (en sentido figurado) más confusa del mundo, el 53 % de las empresas ni siquiera están seguras de que estén trabajando de forma eficaz. Según un estudio del Ponemon Institute. Otro estudio reveló que solo el 17 % de los CISO considera que su pila de seguridad es «totalmente eficaz».
El agotamiento, la escasez de personal especializado en seguridad para satisfacer la demanda y la necesidad de agilidad son factores bien conocidos en este campo, en el que los expertos en seguridad se ven obligados a gestionar una sobrecarga de información en forma de datos, informes y supervisión procedentes de un amplio conjunto de herramientas. Este es precisamente el tipo de situación en la que se pueden pasar por alto alertas importantes al evaluar adecuadamente las vulnerabilidades de Log4j.
La seguridad preventiva debe incluir modelos de amenazas centrados en los desarrolladores.
Las vulnerabilidades a nivel de código suelen ser introducidas por los desarrolladores, y para crear técnicas de codificación seguras se necesitan instrucciones precisas y un plan de aprendizaje regular. Sin embargo, los desarrolladores con un nivel de seguridad más alto tuvieron la oportunidad de aprender y practicar el modelado de amenazas como parte del proceso de desarrollo de software.
No es de extrañar que las personas que mejor conocen su propio software sean los desarrolladores que lo crearon. Estos tienen un profundo conocimiento de cómo interactúan los usuarios con el software, dónde se utilizan las funciones y los posibles escenarios en los que el software podría verse comprometido o ser objeto de abuso si se conoce bien la seguridad.
Si volvemos a este problema con el exploit Log4Shell, lamentablemente se presenta un escenario en el que una vulnerabilidad crítica puede eludir la detección por parte de expertos y conjuntos de herramientas complejas. Sin embargo, si la biblioteca estuviera configurada para eliminar las entradas del usuario, esto no habría ocurrido en absoluto . La decisión de no hacerlo parece haber sido una función ambigua para mayor comodidad, pero se ha vuelto muy fácil de explotar (pensemos en el nivel de inyección SQL, que no es nada genial) . Si un grupo de desarrolladores perspicaces y expertos en seguridad hubiera realizado un modelo de amenazas, es muy probable que hubieran teorizado y considerado este escenario.
Un buen programa de seguridad tiene un elemento emocional en el que la intervención y los matices humanos son clave para resolver los problemas causados por personas. Para que el modelado de amenazas sea efectivo, se necesita empatía y experiencia, lo mismo ocurre con la codificación y la configuración de la seguridad a nivel de arquitectura del software y las aplicaciones. No es necesario que los desarrolladores se dediquen a ello de la noche a la mañana, pero lo ideal sería contar con una hoja de ruta clara para actualizar la tecnología hasta un nivel que alivie la presión del equipo de seguridad sobre esta importante tarea (y que también sea una buena forma de establecer una relación entre ambos equipos).
0일이 n일로 이어집니다
El siguiente paso en la respuesta al día cero es eliminar el parche lo antes posible. Esperamos que todos los usuarios del software vulnerable apliquen el parche lo antes posible y con certeza, antes de que lleguen los atacantes. Log4Shell podría superar a Heartbleed en cuanto a durabilidad y eficacia, ya que está integrado en millones de dispositivos y crea dependencias complejas en toda la compilación del software.
En realidad, no hay forma de bloquear por completo este tipo de ataques astutos. Sin embargo, si nos comprometemos a crear software seguro y de alta calidad utilizando todos los medios a nuestro alcance, y abordamos el desarrollo con la misma mentalidad que se aplica a las infraestructuras críticas, todos tendremos la oportunidad de luchar contra ellos.
