Los ataques de día cero están aumentando. Ahora es el momento de planificar la defensa.

Se ha publicado una versión de este artículo. SC Magazine. Aquí se ha corregido y sindicado.


Si alguna vez ha sufrido un robo en su casa, sabrá que al principio se siente una sensación de inquietud y, después, se da cuenta de que realmente le han robado y violado su intimidad. Huelga decir que la transición a medidas de seguridad comparables a las de Fort Knox suele provocar una sensación de malestar duradera.

Imagina que tu casa ha sido destrozada porque los ladrones han fabricado sus propias llaves. Se cuelan y entran y salen a su antojo, pero tienen cuidado de no llamar la atención. Y entonces, un día, te das cuenta demasiado tarde de que las joyas que guardabas en el congelador han desaparecido, la caja fuerte está vacía y te han robado tus objetos personales.Esto es exactamente lo mismo que le ocurre a una organización cuando es víctima de un ciberataque de día cero. En 2020, una investigación realizada por el Ponemon Institute reveló lo siguiente: El 80 % de las fugas de datos exitosas son 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.

Como es lógico, en un ataque de día cero, el atacante es el primero en entrar, por lo que los desarrolladores no tienen tiempo para encontrar y arreglar las vulnerabilidades existentes que podrían ser explotadas. Cuando se produce el daño, se desata una locura para intentar arreglar tanto el software como la reputación de la empresa. Los atacantes siempre tienen la ventaja, así que es súper importante bloquear esa ventaja tanto como sea posible.

Log4Shell, un regalo navideño que nadie quería, está arrasando actualmente en Internet y se dice que más de mil millones de dispositivos se han visto afectados por esta devastadora vulnerabilidad de Java. Se está convirtiendo en el peor ataque de día cero de la historia, y aún no ha hecho más que empezar. Sin embargo, algunos informes afirman que el exploit comenzó unos días antes de su publicación, una presentación en la conferencia Black Hat de 2016 sugiere que se trata de un problema conocido desde hace tiempo. Qué dolor. Para empeorar las cosas, esta vulnerabilidad es muy fácil de explotar, por lo que todos los script kiddies y actores maliciosos del mundo están apuntando a ella.

Entonces, ¿cuál es la mejor manera de protegerse de las amenazas maliciosas y resbaladizas, por no hablar de las vulnerabilidades que se han pasado por alto en el proceso de desarrollo de software? Veámoslo.

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, por poner un ejemplo, los exploits de día cero suelen alcanzar precios muy elevados. En el momento de escribir este artículo, están cotizando a 2,5 millones de dólares.Aunque se ha informado de que se trata de un exploit para Apple iOS, no es de extrañar que el precio de venta de los investigadores de seguridad se haya disparado. Al fin y al cabo, se trata de una puerta de entrada que podría 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 aplique un parche.

Sin embargo, ¿quién dispone de ese dinero? Normalmente, las organizaciones criminales cibernéticas organizadas obtienen financiación para los ataques de ransomware más populares si consideran que merecen la pena. Sin embargo, los gobiernos y los departamentos de defensa de todo el mundo son clientes de exploits que pueden utilizarse para obtener información sobre amenazas y, en un escenario más positivo, las propias empresas podrían convertirse en compradoras de exploits de día cero potenciales y mitigar así los desastres.

En 2021 se batió el récord. Las organizaciones a gran escala, las agencias gubernamentales y las infraestructuras son las más expuestas al riesgo de ser objeto de descubrimientos en directo de exploits de día cero y de que se investiguen sus vulnerabilidades. No existe una forma de protegerse completamente contra la posibilidad de un ataque de día cero, perose puede «jugar» hasta cierto punto ofreciendo un programa de recompensas por errores generoso y bien estructurado. En lugar de esperar a que alguien ofrezca la llave del castillo del software en el mercado negro de la web oscura, conviene ganarse el apoyo de los entusiastas de la seguridad legítimos y ofrecerles una recompensa adecuada por la divulgación ética y las posibles correcciones.

Y si se trata de una amenaza de día cero que te pone los pelos de punta, no hay duda de que vale la pena pagar más que una tarjeta regalo de Amazon (merece la pena hacerlo).

El uso de herramientas puede suponer una carga para el personal de seguridad.

Las herramientas de seguridad complejas han sido un problema durante mucho tiempo, y 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 afirman que ni siquiera están seguras de que funcionen de forma eficaz. Según un estudio realizado por el Ponemon Institute. Otro estudio reveló que solo el 17 % de los CISO consideran que su pila de seguridad es «totalmente eficaz».

En este campo, conocido por el síndrome de agotamiento, la escasez de personal con habilidades de seguridad que satisfagan la demanda y la necesidad de agilidad, los expertos en seguridad se ven obligados a procesar una gran cantidad de información en forma de datos, informes y supervisión de un enorme conjunto de herramientas, lo que supone una gran carga. Este es precisamente el tipo de escenario que puede dar lugar a que se pasen por alto alertas críticas, algo que también podría ocurrir si se evalúa adecuadamente la vulnerabilidad 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, por lo que para adquirir habilidades de codificación segura se necesita una orientación precisa y un plan de aprendizaje periódico. Sin embargo, los desarrolladores de seguridad de nivel superior tienen la oportunidad de aprender y practicar el modelado de amenazas como parte del proceso de creación de software.

No es de extrañar que las personas que mejor conocen el software de una empresa sean los desarrolladores que se sentaron a crearlo. Si conocen bien cómo utilizan los usuarios el software, dónde utilizan sus funciones y su seguridad, tienen un gran conocimiento de los escenarios en los que el software podría fallar o ser objeto de abuso.

Volviendo al exploit Log4Shell, lamentablemente vemos un escenario en el que ni los expertos ni los complejos conjuntos de herramientas detectan vulnerabilidades críticas. Sin embargo,si la biblioteca se hubiera configurado para sanitizar las entradas de los usuarios, es posible que esto no hubiera ocurrido en absoluto. La decisión de no hacerlo parece haber sido una función ambigua para aumentar la conveniencia, perose volvió muy fácil de explotar (piense en el nivel de inyección SQL. Ciertamente no es algo genial). Si un grupo de desarrolladores entusiastas y conocedores de la seguridad hubiera realizado un modelado de amenazas, es muy probable que este escenario se hubiera teorizado y considerado.

Los programas de seguridad excelentes tienen un componente emocional y se centran en la intervención humana y las sutiles diferencias para resolver los problemas creados por el ser humano. Para realizar un modelado de amenazas eficaz, se necesita empatía y experiencia, así como una codificación y configuración seguras a nivel de arquitectura de software y aplicaciones. No es algo que los desarrolladores puedan abordar de la noche a la mañana, pero lo ideal es establecer una hoja de ruta clara para mejorar las habilidades de los desarrolladores hasta un nivel que permita aliviar la presión del equipo de seguridad en esta importante tarea (Además, es una excelente manera de fomentar la confianza entre ambos equipos).

El día cero conduce a n días.

La siguiente fase de la respuesta al día cero consiste en distribuir el parche lo antes posible. Se espera que todos los usuarios del software vulnerable apliquen el parche lo antes posible y de forma segura, antes de que los atacantes lo hagan. El uso de Log4Shell radica en su durabilidad y eficacia, a pesar de estar integrado en millones de dispositivos que podrían agotar Heartbleed y crear complejas dependencias en toda la compilación del software.

En realidad, no hay forma de impedir por completo este tipo de ataques maliciosos. Sin embargo, si nos comprometemos a crear software seguro y de alta calidad utilizando todos los medios a nuestro alcance, y a desarrollar con la misma mentalidad que se aplica a las infraestructuras críticas, todos tendremos la oportunidad de luchar contra ellos.