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
Cybersecurity Snapshot: U.S. Gov’t Unpacks AI Threat to Banks, as NCSC Urges OT Teams to Protect Cloud SCADA Systems
March 29, 2024Check out new guidance for banks on combating AI-boosted fraud. Plus, how to cut cyber risk when migrating SCADA systems to the cloud. Meanwhile, why CISA is fed up with SQLi flaws. And best practices to prevent and respond to DDoS attacks. And much more!
Cybersecurity Snapshot: NSA Picks Top Cloud Security Practices, while CNCF Looks at How Cloud Native Can Facilitate AI Adoption
March 22, 2024Check out the NSA’s 10 key best practices for securing cloud environments. Plus, learn how cloud native computing could help streamline your AI deployments. Meanwhile, don’t miss the latest about cyberthreats against water treatment plants and critical infrastructure in general. And much more!
FlowFixation: AWS Apache Airflow Service Takeover Vulnerability and Why Neglecting Guardrails Puts Major CSPs at Risk
March 21, 2024Tenable Research discovered a one-click account takeover vulnerability in the AWS Managed Workflows Apache Airflow service that could have allowed full takeover of a victim’s web management panel of the Airflow instance. The discovery of this now-resolved vulnerability reveals a broader problem of misconfigured shared-parent domains that puts customers of major CSPs at risk.
Cybersecurity Snapshot: U.S. Gov’t Unpacks AI Threat to Banks, as NCSC Urges OT Teams to Protect Cloud SCADA Systems
March 29, 2024Check out new guidance for banks on combating AI-boosted fraud. Plus, how to cut cyber risk when migrating SCADA systems to the cloud. Meanwhile, why CISA is fed up with SQLi flaws. And best practices to prevent and respond to DDoS attacks. And much more!
Enhancing Transportation Cybersecurity and Fleet Management for the DoD
March 25, 2024Few things can halt operations across the Department of Defense like a critical failure of logistics and transportation. From automated asset inventory to malicious-activity detections through baselining, learn how Tenable OT Security can protect these critical functions within the DoD and work towards the federal government’s zero trust mandate in OT environments.
Cybersecurity Snapshot: NSA Picks Top Cloud Security Practices, while CNCF Looks at How Cloud Native Can Facilitate AI Adoption
March 22, 2024Check out the NSA’s 10 key best practices for securing cloud environments. Plus, learn how cloud native computing could help streamline your AI deployments. Meanwhile, don’t miss the latest about cyberthreats against water treatment plants and critical infrastructure in general. And much more!
- Cloud
- Container security
- Continuous Monitoring
- Incident Response
- Log Analysis
- Threat Intelligence
- Threat Management
- Vulnerability Management
- Vulnerability Scanning