A medida que las organizaciones de todo el mundo se esfuerzan por abordar la vulnerabilidad crítica de Log4j, conocida como Log4Shell, la pregunta número uno en la mente de todos los líderes de seguridad es: ¿Cómo sé si tengo esto?
Cómo Apache Log4j Flaw pone el software de terceros en el centro de atención. La absoluta ubicuidad de Apache Log4j, un marco de trabajo de registro de código abierto hace que esta sea una pregunta particularmente difícil de responder.
Muchas organizaciones no solo usan Log4j en su propio código fuente, sino que también se usa en muchos de los productos que estas organizaciones adquieren de terceros. Las organizaciones que han adoptado el enfoque de «cambio a la izquierda» para su ciclo de vida de desarrollo de software seguro (SSDL) pueden analizar su propio código fuente para encontrar y corregir la falla en sus propios sistemas.
Se necesita un enfoque SSDL que incluya pruebas de seguridad de aplicaciones estáticas (SAST), pruebas de seguridad de aplicaciones dinámicas (DAST), verificación de dependencias de terceros, escaneo de seguridad de contenedores, administración de vulnerabilidades e Infraestructura como código (IaC). Pero incluso con todas esas prácticas implementadas, las organizaciones seguirán luchando por captar todo lo que está en el lado izquierdo. La administración de vulnerabilidades y el escaneo de aplicaciones web también son cruciales, particularmente cuando se trata de su software de terceros. No es suficiente descubrir si la falla existe o no, también necesita comprender el nivel de riesgo que representa en el contexto de la combinación de aplicaciones, activos y procesos comerciales de su organización.
Aunque la reciente orden ejecutiva de la Administración de Biden exige que las organizaciones desarrollen una lista de materiales de software (SBOM), la mayoría de los proveedores no proporcionan SBOM para su software. E incluso si lo hicieran, la mayoría de las organizaciones están a años luz de tener los procesos y las capacidades para hacer un uso efectivo de ellos. Entonces, cuando ocurre un incidente como log4j, los líderes de ciberseguridad tienen una opción: llamar a sus proveedores externos y preguntarles. Esto es arduo, redundante y requiere mucho tiempo, lo que deja a las organizaciones en un lío incluso cuando los atacantes se apresuran a explotar la falla.
Incluso en las organizaciones más maduras, donde las prácticas SSDL y SBOM están arraigadas en los procesos, persisten brechas que dificultan que las organizaciones de seguridad respondan estas cinco preguntas cruciales:
¿Los ejecutamos en nuestros entornos?
¿Qué tal en nuestra infraestructura?
¿Qué tal en nuestras propias tuberías de construcción? ‘
¿Qué hay de los proveedores de nuestra infraestructura? (este punto es especialmente pertinente si está utilizando servicios de proveedor de servicios en la nube)
Dado que el análisis de composición de software (SCA) no detecta todas las instancias de Log4J, ¿hemos ejecutado otros controles, como Infraestructura como código (IaC), gestión de vulnerabilidades y escaneo de aplicaciones web, contra todos los componentes de nuestro código?
La conclusión es la siguiente: no hay una solución fácil para Log4j. Ya se ha demostrado que una opción obvia, implementar un firewall de aplicaciones web, es bastante fácil de eludir. Una organización responsable debe hacer el trabajo de actualizar su software central y comprender cómo esta falla afecta el perfil de riesgo general. Las organizaciones que responden ahora están tomando decisiones en modo de crisis; una vez que la crisis inicial haya pasado, la tentación será declarar “misión cumplida” y alejarse. En nuestra opinión, se trata de un error catastrófico. Ya es hora de que las organizaciones hagan el arduo trabajo de arreglar su infraestructura y mantener sus sistemas con un enfoque de seguridad primero incorporado.
Tenable esta comprometido con SSDL y esta tomando las siguientes acciones en respuesta a Log4j:
Tienen puertas de bloqueo y en este caso, están bloqueando el uso de cualquier instancia vulnerable de software, para incluir Log4j.
Realizan de forma activa y constante análisis de gestión de vulnerabilidades y análisis de aplicaciones web en toda su infraestructura y el código de producto previo al lanzamiento antes de que se envíe a los clientes.
Además, se ha actuado sobre todos los indicadores de compromiso y ataque y han implementado controles en los niveles de red y host.
Continuarán monitoreando la inteligencia de amenazas para rastrear el panorama de amenazas y realizar ajustes según sea necesario. Al final, responder a cualquier incidente consiste en saber qué hay en su entorno, conocer su superficie de ataque, incluidos todos los terceros, y reducir el riesgo rápidamente.
El tiempo es la esencia, los adversarios siempre están listos para aprovechar las últimas vulnerabilidades y reutilizarlas para sus propios casos de uso. Las organizaciones deben hacer todo lo posible para analizar detenidamente sus prácticas ahora, ya que los efectos domino de este incidente afectarán al software empresarial durante los próximos años.
Feunte: Tenable Robert Huber Director de seguridad y jefe de investigación de Tenable
https://es-la.tenable.com/log4j
¿Que tan preparado estas para defenderte de esta vulnerabilidad? con BG2 puede detectarla y monitorearla, Acércate a los especialistas, agenda una sesión hoy mismo.
Conoce más de BG2 Services
