Los ataques sin reparar están aumentando. Es hora de planificar una ventaja defensiva.

Una versión de este artículo apareció en revista SC. Aquí se ha modificado y publicado conjuntamente.


Si alguna vez te han robado en tu casa, comprenderás la sensación inicial de desconcierto, de que algo ha pasado, y luego te das cuenta de que realmente te han robado y violado tu intimidad. Esto suele provocar un malestar continuo, por no hablar de la necesidad de adoptar medidas de seguridad comparables a las de Fort Knox.

Ahora imagina que tu casa ha sido allanada porque los ladrones se han hecho una copia de la llave. Se mueven por todas partes, entran y salen a su antojo, pero con cuidado para no ser descubiertos. Entonces, un día, descubres que las joyas que guardabas en la nevera han desaparecido, la caja fuerte está vacía y tus objetos personales han sido saqueados.ya es demasiado tarde. Esto es lo mismo que le pasa a una organización cuando es víctima de un ataque cibernético de día cero. En 2020, un estudio del Instituto Ponemon mostró que el 80 % de las filtraciones de datos exitosas son el resultado de vulnerabilidades sin parchear y, lamentablemente, la mayoría de las empresas siguen sin poder mejorar mucho esta estadística.

Como su nombre indica, los ataques de día cero impiden a los desarrolladores detectar y corregir las vulnerabilidades existentes que podrían ser explotadas, ya que los actores maliciosos se adelantan a ellos. El daño ya está hecho, y entonces comienza una carrera frenética para reparar el software y la reputación de la empresa. Los atacantes siempre llevan la ventaja, por lo que es fundamental reducirla al mínimo.

El regalo navideño que nadie quería, Log4Shell, está destrozando Internet en estos momentos. Se dice que más de mil millones de dispositivos se han visto afectados por esta catastrófica vulnerabilidad de Java. Será el ataque de día cero más grave jamás registrado, y esto no ha hecho más que empezar. Aunque algunos informes indican que el aprovechamiento de la vulnerabilidad comenzó unos días antes de su divulgación pública, una presentación realizada en la conferencia Black Hat de 2016 sugiere que se trata de un problema conocido desde hace tiempo. Vaya. Lo peor es que es fácil de explotar y todos los guionistas y actores maliciosos del planeta están aprovechando esta vulnerabilidad para obtener beneficios.

Entonces, ¿cuál es la mejor manera de avanzar para prevenir amenazas ridículas y peligrosas, por no hablar de las vulnerabilidades que se pasan por alto durante el proceso de desarrollo de software? Veámoslo.

Los ataques de día cero dirigidos a objetivos de gran envergadura son poco frecuentes (y muy costosos).

El mercado de exploits en la dark web es enorme, y los exploits de día cero suelen costar mucho dinero. Por ejemplo, en este artículo, en el momento de redactar este artículo, el precio de venta era de 2,5 millones de dólares. Según se informa, se trata de un exploit de iOS de Apple, por lo que no es de extrañar que los investigadores de seguridad pidan un precio tan alto; al fin y al cabo, podría ser una puerta de entrada para invadir millones de dispositivos, recopilar miles de millones de registros de datos confidenciales y llevar a cabo ataques durante el mayor tiempo posible antes de que se descubran y se corrijan.

Pero, en cualquier caso, ¿quién tiene tanto dinero? Por lo general, si consideran que el dinero en efectivo vale la pena, las redes criminales organizadas lo aceptan, especialmente en el caso de los ataques de ransomware, que son muy populares. Sin embargo, los gobiernos y los departamentos de defensa de todo el mundo son clientes potenciales de la inteligencia sobre amenazas, y en el mejor de los casos, estas mismas empresas podrían comprar sus propias vulnerabilidades potenciales sin parchear para poder mitigar el desastre.

El año 2021 batió récords en el descubrimiento de vulnerabilidades sin parchear en tiempo real, y las grandes organizaciones, los departamentos gubernamentales y las infraestructuras son los más propensos a ser investigados por cualquier vulnerabilidad. No hay forma de protegerse completamente contra la posibilidad de un ataque de día cero, pero puedes jugar a «jugar». En lugar de esperar a que alguien ofrezca la llave del castillo del software en el mercado negro, es mejor tener a los entusiastas de la seguridad legítimos de su lado, ofreciéndoles generosas recompensas por la divulgación ética y las posibles correcciones.

Además, si se trata de una nueva amenaza de vulnerabilidad espeluznante, se puede decir con certeza que necesitarás algo más que una tarjeta regalo de Amazon (y vale la pena dedicarle tiempo).

Tus herramientas pueden ser responsabilidad de tu personal de seguridad.

Las herramientas de seguridad complejas han sido un problema desde hace mucho tiempo, y los directores de seguridad de la información suelen gestionar 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 seguras de su eficacia, según un estudio realizado por el Instituto Ponemon. Otro estudio revela que solo el 17 % de los CISO consideran que su pila de seguridad es «totalmente eficaz».

En un sector caracterizado por el agotamiento, la falta de personal cualificado en materia de seguridad para satisfacer la demanda y la necesidad de flexibilidad, obligar a los profesionales de la seguridad a gestionar la sobrecarga de información en forma de datos, informes y supervisión de grandes conjuntos de herramientas supone una carga considerable. Esta es precisamente la situación que puede llevarles a pasar por alto alertas críticas, como probablemente ocurrió al evaluar correctamente 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, quienes necesitan orientación precisa y vías de aprendizaje periódicas para desarrollar habilidades de codificación seguras. Sin embargo, como parte del proceso de creación de software, los desarrolladores de seguridad de nivel inferior tienen la oportunidad de aprender y practicar el modelado de amenazas.

No es de extrañar que quienes mejor conocen el software sean los desarrolladores que se sientan a crearlo. Tienen un profundo conocimiento de cómo interactúan los usuarios con él, dónde utilizan esas funciones y cuándo tienen suficiente conciencia de seguridad, así como de los posibles escenarios en los que podría verse comprometido o ser objeto de abuso.

Si volvemos a centrar la atención en la vulnerabilidad Log4Shell, lamentablemente vemos que se trata de una vulnerabilidad catastrófica que escapó a la detección de los expertos y de un complejo conjunto de herramientas.Sin embargo, si la biblioteca se hubiera configurado para desinfectar las entradas de los usuarios, es posible que esto no hubiera ocurrido. La decisión de no hacerlo, tomada para aumentar la comodidad, parece una función insignificante, peroes muy fácil de explotar (pensemos en el nivel de inyección SQL, que, por supuesto, no es algo muy sofisticado). Si el modelado de amenazas lo hubiera realizado un grupo de desarrolladores perspicaces y expertos en seguridad, es muy probable que este escenario se hubiera teorizado y tenido en cuenta.

Un buen plan de seguridad tiene un componente emocional, y la intervención humana y los matices son fundamentales para resolver los problemas humanos. 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 arquitectura de software y aplicaciones. No es algo en lo que los desarrolladores deban sumergirse de la noche a la mañana, pero es una forma clara de mejorar sus habilidades hasta el punto de poder aliviar la presión sobre el equipo de seguridad para que este pueda realizar esta importante tarea, lo cual es ideal (y también una buena forma de establecer una buena relación entre ambos equipos).

El día cero provoca n días.

La siguiente parte del proceso para tratar las vulnerabilidades no corregidas es publicar los parches lo antes posible. Es muy importante que todos los usuarios del software vulnerable apliquen los parches lo antes posible, por supuesto, antes de que los atacantes lleguen allí primero. Con Log4Shell, podría eclipsar a Heartbleed. Dada su incrustación en millones de dispositivos y las complejas dependencias que genera en todas las versiones de software, su durabilidad y eficacia son muy fuertes.

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