Por qué las vulnerabilidades de Log4j resaltan la importancia de DevSecOps

En diciembre de 2021, los equipos de seguridad de TI y las organizaciones de desarrollo de todo el mundo recibieron una grosera llamada de atención. Los investigadores descubrieron una grave vulnerabilidad de seguridad en la utilidad Apache Log4j, un popular componente de registro integrado en innumerables aplicaciones y servicios Java. Las noticias de esta vulnerabilidad hicieron que los equipos de seguridad de TI y las organizaciones de desarrollo se apresuraran a encontrar todas las instancias de las versiones vulnerables de Log4j en sus propias redes.

La vulnerabilidad Log4j también obligó a los equipos de DevSecOps a responder una pregunta que ahora se siente menos teórica. Si Log4j o cualquier otra vulnerabilidad comprometiera una aplicación desarrollada internamente, ¿los equipos de seguridad podrían aislar el ataque y mitigar su daño? ¿Las prácticas actuales de DevOps preparan para que una organización vaya a la caza de amenazas de manera rápida y efectiva a través de su propio código?

Echemos un vistazo rápido a la vulnerabilidad Log4j, lo que significa para los equipos de DevSecOps y cómo la segmentación de confianza cero de Illumio puede ayudar a los equipos de DevSecOps a mitigar las amenazas cuando se ataca el software vulnerable antes de que se pueda solucionar.

La vulnerabilidad Log4j y por qué es importante

La vulnerabilidad que recibe toda esta atención involucra el uso de Log4j de Java Naming and Directory Interface (JNDI), una popular API de nomenclatura y búsqueda para aplicaciones Java. Las primeras versiones de Log4j habilitaron la función de sustitución de búsqueda de mensajes de JNDI de forma predeterminada. Con esa función, los atacantes pueden enviar mensajes cuidadosamente construidos a una aplicación, lo que obliga a la aplicación a ejecutar código cargado desde servidores LDAP u otros puntos finales bajo el control del atacante. Ese código podría instalar malware, filtrar datos o realizar otras acciones maliciosas en la red de la aplicación.

Log4j es ampliamente empleado. Google estima que está en el 4 por ciento de los paquetes de Java en el Repositorio Central de Maven, ampliamente reconocido como el repositorio de paquetes de Java más importante. Log4j se emplea en todo tipo de software, desde aplicaciones sitio web hasta servicios de back-end y aplicaciones personalizadas para dispositivos IoT.

Tan pronto como se anunció esta vulnerabilidad, los equipos de seguridad de TI comenzaron a rastrear sus redes, buscando nombres de archivos y otras indicaciones de la presencia de Log4j en cualquier directorio de su entorno. Los equipos de DevOps también se pusieron manos a la obra, buscando en sus propios archivos cualquier uso de Log4j en sus propias aplicaciones.

Hay mucho en juego. Los ciberdelincuentes ya emplearon esta vulnerabilidad para lanzar ataques de ransomware, instalar software de minería de monedas en redes corporativas e infiltrar en el Ministerio de Defensa belga. Los atacantes están diseñando nuevas formas de malware dirigidas a la vulnerabilidad. Por ejemplo, el nuevo ransomware Night Sky se dirige a las vulnerabilidades de Log4j en el software VMware Horizon.

El panorama general: vulnerabilidades del código fuente y los riesgos que plantean

La vulnerabilidad Log4j destaca dos problemas más grandes para las organizaciones de desarrollo internas. En primer lugar, no importa qué tan bien organizados estén sus herramientas y procesos de DevOps, la mayoría de las organizaciones tienen dificultades para determinar todos los componentes empleados en sus aplicaciones, especialmente si esos componentes están integrados como bibliotecas o se accede a ellos a través de dependencias con otros servicios.

En el caso de Log4j, por ejemplo, es posible incluir la utilidad en una aplicación sin dejar un archivo JAR de Log4j en un repositorio. Encontrar todas las versiones de todos los componentes de software, de código abierto o de otro tipo, en las aplicaciones es un trabajo difícil y lento.

En segundo lugar, si se descubre que una aplicación está siendo atacada debido a una vulnerabilidad, los equipos de seguridad necesitan una forma de aislar el ataque inmediatamente antes de que el ataque pueda propagar a otros sistemas de la red.

Detectar y detener los ataques de Log4j es importante no solo para proteger los datos confidenciales y garantizar la continuidad operativa, aunque esos objetivos son obviamente críticos.

Pero también hay un ángulo de cumplimiento. El 4de enero de 2022, la Comisión Federal de Comercio de EE. UU. (FTC) anunció que aplicaría sanciones y multas a las compañías que permitieran que se violaran datos confidenciales de los consumidores como resultado de las vulnerabilidades de Log4j.

Citando su multa de 700 millones de dólares contra Equifax por filtrar datos de consumidores debido a una vulnerabilidad sin parches en el marco Apache Struts, la FTC anunció que "tiene la intención de usar toda su autoridad legal para perseguir a las compañías que no tomen medidas razonables para proteger los datos de los consumidores de la exposición como resultado de Log4j o vulnerabilidades conocidas similares en el futuro".

Resulta que Log4j es la punta de un enorme iceberg de amenazas potenciales. Para encontrar y corregir vulnerabilidades no solo relacionadas con Log4j, sino también con cualquier componente de software en sus propias aplicaciones o aplicaciones de terceros que estén ejecutando, las compañías necesitan una visibilidad completa de sus entornos de software. No encontrar estas vulnerabilidades antes de que resulten en una violación de datos puede generar fuertes multas regulatorias y daños duraderos a la marca de una organización.

Afortunadamente, DevSecOps puede ayudar.

El papel de DevSecOps en la mitigación de las amenazas de vulnerabilidad de software

La idea detrás de DevSecOps es simple: la seguridad no debería ser una ocurrencia tardía cuando se trata de desarrollar e implementar software. En cambio, la seguridad debe incluir en cada paso de DevOps, desde el diseño hasta el desarrollo, las pruebas, el lanzamiento y la gestión de operaciones. DevSecOps es la práctica de incorporar seguridad en las aplicaciones de software desarrolladas y gestionadas a través de procesos DevOps.

¿Cómo puede DevSecOps ayudar a abordar problemas como la vulnerabilidad Log4j?

En primer lugar, las mejores prácticas de DevSecOps requerirían que los equipos de desarrollo usen versiones actualizadas de componentes como Log4j al crear y gestionar aplicaciones.

En segundo lugar, DevSecOps también pediría a las organizaciones de desarrollo y prueba que rastreen las versiones de todos los componentes, incluidos los componentes de código abierto, empleados en las aplicaciones. De esa manera, si la comunidad de seguridad de TI anuncia una vulnerabilidad en un componente en individuo, la organización DevSecOps puede determinar rápidamente cuáles de sus propias aplicaciones, si las hay, se ven afectadas.

Igualmente importante, las mejores prácticas de DevSecOps requerirían la incorporación de controles de seguridad dentro de las aplicaciones, de modo que cuando, inevitablemente, se descubra que otra biblioteca o componente de código abierto es vulnerable, los equipos puedan estar preparados para contener cualquier ataque de día cero contra esa vulnerabilidad de manera rápida y efectiva. Si ya existen medidas defensivas, la organización puede actuar para defender de un ataque, incluso si falta días o semanas para un parche para la vulnerabilidad.

Uno de los mejores controles de seguridad para integrar es una solución de segmentación de confianza cero que emplea los firewalls integrados en los sistemas para aplicar políticas de seguridad que limitan el tráfico de red solo a usuarios y procesos autorizados. Al reducir significativamente las rutas de red disponibles para los atacantes, Zero Trust Segmentation encierra a los atacantes, aislándolos en los pocos sistemas que inicialmente podrían lograr comprometer. Con la segmentación de confianza cero implementada, los atacantes no podrían descargar y ejecutar código de un sitio malicioso.

Si un ataque está aislado en la red, los ciberdelincuentes no pueden propagar el ransomware a otros sistemas. No pueden explorar sigilosamente la red, buscando datos valiosos para filtrar. Están atrapados en su lugar como un desafortunado ladrón que logró caer a través de un tragaluz solo para encontrar en una trampa para osos. Entraron, pero no van a ir a ninguna parte. Y sonó una alarma.

Illumio proporciona la visibilidad y la automatización que necesitan los equipos de DevSecOps

Illumio Zero Trust Segmentation es una valiosa solución de seguridad para cualquier organización de DevSecOps porque facilita a los equipos de desarrollo la incorporación de rigurosos controles de seguridad en las aplicaciones sin tener que aprender las complejidades de la red o las prácticas de seguridad.

Illumio protege las aplicaciones facilitando a los desarrolladores y a los equipos de seguridad la definición de políticas de segmentación de confianza cero. Una vez creadas, las organizaciones pueden hacer cumplir fácilmente esas políticas empleando el nodo de aplicación virtual (VEN) de Illumio junto con los firewalls basados en host ya integrados en los sistemas donde se ejecutan las aplicaciones de la organización. El Illumio VEN es un cliente liviano y a prueba de fallas que se puede incluir fácilmente en compilaciones de software. No se requieren cambios de diseño extensos.

La solución Illumio emplea firewalls, pero ahorra a los desarrolladores la molestia de tener que programar conjuntos complejos de reglas de firewall. En cambio, permite a los desarrolladores y al equipo de seguridad definir las políticas que desean aplicar, permitiendo que solo el tráfico necesario pase a través de sus aplicaciones, y luego enviar esas políticas a los VEN incrustados en las aplicaciones para su aplicación.

Las organizaciones de DevSecOps pueden ajustar las políticas para varias aplicaciones y entornos. Específicamente, pueden definir políticas basadas en:

• Roles dentro de la aplicación
• La aplicación en sí
• El entorno en el que se ejecuta la aplicación, como desarrollo, prueba o producción
• La ubicación del entorno: por ejemplo, un entorno de producción en un centro de datos de la costa oeste de EE. UU.

Luego, el equipo de DevSecOps simplemente agrega un VEN de Illumio a una compilación de software. Una vez que se ejecuta en el entorno de la aplicación, el VEN aplica políticas de confianza cero, genera alertas al detectar movimientos laterales sospechosos y reduce el tráfico en respuesta a ataques activos, aislando los puntos finales infectados del resto de la red.

Illumio también ofrece un cliente C-VEN y un servicio Kubelink para su uso en entornos en contenedores, que son populares en las arquitecturas de microservicios. C-VEN es un agente ligero de Illumio, que se ejecuta como un pod en cada nodo de un clúster de Kubernetes, que protege el nodo y todos los pods que se ejecutan en él. Entregado como un DaemonSet, C-VEN se escala hacia arriba y hacia abajo a medida que evoluciona el clúster. Kubelink es un servicio de Illumio que monitorea el servidor de API de Kubernetes para obtener información sobre los recursos dentro del clúster y proporcionar contexto de Kubernetes al PCE. Se entrega como un paquete y requiere solo una réplica por clúster, lo que ayuda a que las soluciones de contenedores de Illumio sean altamente escalables.

Los equipos de DevSecOps tienen dos formas de interactuar con el PCE de Illumio: a través de la interfaz de usuario de PCE o sus API REST bien documentadas. Los equipos de DevSecOps pueden usar las API para integrar Illumio en canalizaciones de CI/CD, de modo que la segmentación de confianza cero se convierta en una parte estándar de los flujos de trabajo de DevSecOps. Las API también permiten a los equipos de seguridad integrar Illumio con otras herramientas y flujos de trabajo de seguridad.

El conjunto de productos Illumio proporciona segmentación de confianza cero dondequiera que se implementen aplicaciones y servicios, incluidos los puntos finales en:

• Centros de datos: Illumio Core
• Nubes públicas, privadas o híbridas: Illumio CloudSecure
• Dispositivos de punto final: Illumio Edge

Log4j no será el último componente de software que incluya una vulnerabilidad peligrosa. Al adoptar las prácticas de DevSecOps y usar Illumio para aplicar la segmentación de confianza cero en aplicaciones de todo el mundo, las organizaciones pueden estar preparadas para proteger sus datos, aplicaciones y personas mientras continúa el trabajo de escaneo de red y búsqueda de amenazas.

Para obtener más información:

• Consulte el resumen de la solución, Illumio para DevSecOps.
• Contáctenos para una demostración.