La falla en Apache Log4j coloca al software de terceros bajo los reflectores
por Robert Huber
Página de inicio del Blog / Alertas de exposición cibernética
En la medida en que las organizaciones en todo el mundo batallan para abordar la vulnerabilidad crítica Log4j, conocida como Log4Shell, la pregunta en la mente de todo líder de equipo de seguridad es: ¿cómo puedo saber si esto me ha invadido?
Actualización 17 de diciembre: Apache ha actualizado la gravedad de CVE-2021-45046, una segunda vulnerabilidad de Log4j, de baja a crítica (9.0 CVSSv3) mencionando una posible RCE bajo determinadas configuraciones. Para obtener más información, consulte esta publicación en Tenable Community.
La absoluta ubicuidad de Apache Log4j, un marco de registro de código abierto, hace que esta sea una pregunta particularmente difícil de responder.
Muchas organizaciones utilizan Log4j en su propio código fuente, pero también se utiliza en muchos de los productos que estas organizaciones adquieren de terceros. Las organizaciones que han adoptado el abordaje de “acelerar la detección” en su ciclo de vida de desarrollo de software seguro (SSDL), pueden analizar su propio código fuente para detectar y reparar la falla en sus propios sistemas.
Un abordaje de SSDL que incluye pruebas de seguridad de aplicaciones estáticas (SAST), pruebas de seguridad de aplicaciones dinámicas (DAST), comprobación de dependencias de terceros, escaneo de seguridad de contenedores, gestión de vulnerabilidades e infraestructura como código (IAC) conforme sea necesario. Pero incluso con todas esas prácticas implementadas, las organizaciones seguirán luchando para capturar todo lo que hay rápidamente. La gestión de vulnerabilidades y el escaneo de aplicaciones web también son cruciales, especialmente cuando se trata de software de terceros. No basta con descubrir si existe o no la falla, sino que también es necesario comprender el nivel de riesgo que representa en el contexto de la combinación de aplicaciones, activos y procesos de negocios de su organización.
Aunque el reciente decreto del gobierno de Biden pide a las organizaciones que desarrollen una lista de materiales de software (SBOM), la mayoría de los proveedores no suministran SBOM para su software. E incluso si lo hacen, la mayoría de las organizaciones permanecen a años luz de contar con los procesos y las capacidades para hacer un uso eficaz de ellas. Por lo tanto, cuando se produce un incidente como el de log4j, los líderes de ciberseguridad tienen una opción: llamar a sus proveedores terceros y preguntarles. Esta es una labor ardua, redundante y que requiere mucho tiempo, lo que genera mucho revuelo en las organizaciones, incluso cuando los atacantes se apresuran a explotar la falla.
Solo las preguntas frecuentes: CVE-2021-45046, CVE-2021-4104:Preguntas frecuentes acerca de Log4Shell y vulnerabilidades asociadas.
Hasta en las organizaciones más maduras, donde las prácticas de SSDL y las SBOM están arraigadas en los procesos, siguen existiendo brechas que hacen difícil que las organizaciones de seguridad respondan a estas cinco preguntas fundamentales:
- ¿Los ejecutamos en nuestros entornos?
- ¿Y en nuestra infraestructura?
- ¿Y en nuestros propios pipelines?
- ¿Y los proveedores de nuestra infraestructura? (este punto es especialmente pertinente si utilizan servicios de proveedor de servicios en la nube)
- Dado que el análisis de composición de software (SCA) no descubrirá todas las instancias de Log4J, ¿hemos ejecutado otros controles, como la infraestructura como el código (IAC), la gestión de vulnerabilidades o el escaneo de aplicaciones web en todos los componentes de nuestro código?
La conclusión es la siguiente: No hay una reparación fácil para Log4j. Ya se ha demostrado que una opción obvia, la implementación de un firewall de aplicaciones web, es bastante fácil de eludir. Una organización responsable debe actualizar su software principal y comprender cómo esta falla afecta al 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á decir “misión cumplida” y olvidarse. Nosotros pensamos que ese, es un error catastrófico. Ya hemos llegado al momento de que las organizaciones realicen el duro trabajo de reparar su infraestructura y mantener sus sistemas con un abordaje basado en la seguridad.
En Tenable estamos comprometidos con el SSDL y estamos tomando las siguientes medidas en respuesta a Log4j:
- Tenemos compuertas de bloqueo y, en este caso, estamos bloqueando el uso de cualquier instancia vulnerable de software, para incluir Log4j.
- Realizamos de forma activa y constante escaneos de gestión de vulnerabilidades y escaneos de aplicaciones web en toda nuestra infraestructura y código de productos previamente a su lanzamiento, antes de su envío a los clientes.
- Además, hemos puesto en práctica todos los indicadores de riesgo y ataque y hemos implementado controles a nivel de red y host.
Seguiremos monitoreando la inteligencia de amenazas para realizar un seguimiento del panorama de amenazas y realizar ajustes según sea necesario. Al final, responder a cualquier incidente consiste en saber qué hay en su entorno y conocer su superficie de ataque, incluidos los dispositivos de terceros, y reducir rápidamente el riesgo. El tiempo es fundamental. Los adversarios están siempre dispuestos a aprovechar las vulnerabilidades más recientes y a utilizarlas en su beneficio. Las organizaciones deben hacer todo lo posible para analizar sus prácticas ahora, ya que los efectos de este incidente afectarán al software empresarial durante los próximos años.
Más información
- Visite el centro de soluciones de Tenable Log4j: https://www.tenable.com/log4j
- Lea la alerta SRT: CVE-2021-44228:Prueba de concepto para la vulnerabilidad de ejecución remota de código crítica en Apache Log4j disponible (Log4Shell)
- Lea las Preguntas frecuentes: CVE-2021-44228, CVE-2021-45046, CVE-2021-4104: Preguntas frecuentes acerca de Log4Shell y vulnerabilidades asociadas
- Lea la perspectiva del CTO: Falla de Apache Log4j: El fantasma de Fukushima en el sector de ciberseguridad
- Visite nuestra comunidad de usuarios para obtener más información de cómo Tenable puede ayudarle: https://community.tenable.com/s/
Artículos relacionados
How the regreSSHion Vulnerability Could Impact Your Cloud Environment
July 5, 2024With growing concern over the recently disclosed regreSSHion vulnerability, we’re explaining here what it is, why it’s so significant, what it could mean for your cloud environment and how Tenable Cloud Security can help.
Cybersecurity Snapshot: Memory Bugs Pervasive in Open Source SW, While Car Dealership Chaos Persists After Ransomware Attack
June 28, 2024Check out why memory vulnerabilities are widespread in open source projects. Plus, get the latest on the ransomware attack that’s disrupted car sales in North America. In addition, find out why a majority of organizations grew their cyber budgets this year. And learn how confidential data from U.S. chemical facilities may have been accessed by hackers. And much more!
Tag, You’re IT! Tagging Your Way to Cloud Security Excellence
June 26, 2024To manage your cloud resources effectively and securely, you need to consistently tag assets across all your cloud platforms. Here we explain tagging’s main benefits, as well as proven strategies and best practices for tagging success.
How Risk-based Vulnerability Management Boosts Your Modern IT Environment's Security Posture
July 11, 2024Vulnerability assessments and vulnerability management sound similar – but they’re not. As a new Enterprise Strategy Group white paper explains, it’s key to understand their differences and to shift from ad-hoc vulnerability assessments to continuous, risk-based vulnerability management (RBVM). Read on to check out highlights from this Tenable-commissioned study and learn how RBVM helps organizations attain a solid security and risk posture in hybrid, complex and multi-cloud environments.
Microsoft’s July 2024 Patch Tuesday Addresses 138 CVEs (CVE-2024-38080, CVE-2024-38112)
July 9, 2024Microsoft addresses 138 CVEs in its July 2024 Patch Tuesday release, with five critical vulnerabilities and three zero-day vulnerabilities, two of which were exploited in the wild.
How the regreSSHion Vulnerability Could Impact Your Cloud Environment
July 5, 2024With growing concern over the recently disclosed regreSSHion vulnerability, we’re explaining here what it is, why it’s so significant, what it could mean for your cloud environment and how Tenable Cloud Security can help.
- Cloud
- Container security
- Continuous Monitoring
- Incident Response
- Log Analysis
- Threat Intelligence
- Threat Management
- Vulnerability Management
- Vulnerability Scanning