Por qué las vulnerabilidades de Log4j destacan 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 llamada de atención grosera. Los investigadores habían descubierto una grave vulnerabilidad de seguridad en la utilidad Apache Log4j, un popular componente de registro integrado en innumerables aplicaciones y servicios Java. La noticia de esta vulnerabilidad hizo que los equipos de seguridad de TI y las organizaciones de desarrollo se esfuercen por encontrar todas las instancias de las versiones vulnerables de Log4j en sus propias redes.

La vulnerabilidad Log4j también ha obligado 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 búsqueda de amenazas de manera rápida y efectiva a través de su propio código?

Echemos un vistazo rápido a la vulnerabilidad de 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 el software vulnerable es atacado antes de que se pueda solucionar.

La vulnerabilidad Log4j y por qué es importante

La vulnerabilidad que recibe toda esta atención implica El uso de Log4j de la interfaz de directorio y nomenclatura de Java (JNDI), una popular API de nombres 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. Al usar 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, exfiltrar datos o realizar otras acciones maliciosas en la red de la aplicación.

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

Tan pronto como se anunció esta vulnerabilidad, los equipos de seguridad de TI comenzaron a recorrer 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 ocupados, buscando a través de sus propios archivos buscando cualquier uso de Log4j en sus propias aplicaciones.

Hay mucho en juego. Los ciberdelincuentes ya han utilizado esta vulnerabilidad para lanzar ataques de ransomware, instalar software de minería de monedas en redes corporativas e infiltrarse 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 apunta Vulnerabilidades de Log4j en el software VMware Horizon.

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

La vulnerabilidad Log4j resalta dos problemas mayores para las organizaciones de desarrollo interno. Primero, no importa cuán bien organizados estén sus herramientas y procesos DevOps, la mayoría de las organizaciones tienen dificultades para determinar todos los componentes utilizados 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 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á bajo ataque debido a una vulnerabilidad, los equipos de seguridad necesitan una forma de aislar el ataque inmediatamente antes de que el ataque pueda propagarse a otros sistemas de la red.

Detener 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 4 de enero de 2022, el La Comisión Federal de Comercio de Estados Unidos (FTC) anunció que aplicaría sanciones y multas contra empresas que permitían que se violara la información confidencial de los consumidores como resultado de las vulnerabilidades de Log4j.

Citando su Sanción de 700 millones de dólares contra Equifax por filtrar datos de los consumidores debido a una vulnerabilidad sin parches en el marco Apache Struts, la FTC anunció que “tiene la intención de utilizar su plena autoridad legal para perseguir a las empresas 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”.

Log4j, resulta, es la punta de un iceberg masivo de amenazas potenciales. Para encontrar y solucionar vulnerabilidades no solo relacionadas con Log4j sino con cualquier componente de software en sus propias aplicaciones o aplicaciones de terceros que están ejecutando, las empresas necesitan una visibilidad completa de sus entornos de software. No encontrar estas vulnerabilidades antes de que resulten en una violación de datos puede dar lugar a 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 amenazas de vulnerabilidad de software

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

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

En primer lugar, las mejores prácticas de DevSecOps requieren que los equipos de desarrollo utilicen versiones actualizadas de componentes como Log4j al crear y administrar aplicaciones.

En segundo lugar, DevSecOps también llamaría a las organizaciones de desarrollo y pruebas para rastrear las versiones de todos los componentes, incluidos los componentes de código abierto, utilizados en las aplicaciones. De esa manera, si la comunidad de seguridad de TI anuncia una vulnerabilidad en un componente en particular, 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 requieren la incorporación de controles de seguridad dentro de las aplicaciones, de modo que cuando, inevitablemente, se encuentre vulnerable otra biblioteca o componente de código abierto, los equipos puedan estar preparados para contener cualquier ataques de día cero contra esa vulnerabilidad de manera rápida y efectiva. Si ya existen medidas defensivas, la organización puede actuar para defenderse de un ataque, incluso si faltan días o semanas para un parche para la vulnerabilidad.

Uno de los mejores controles de seguridad para incrustar es una solución de Segmentación de Confianza Cero que utiliza 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 drásticamente los paths de red disponibles para los atacantes, la Segmentación de Confianza Cero incluye a los atacantes y los aísla en los pocos sistemas que inicialmente podrían llegar a 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 se aísla en la red, los ciberdelincuentes no pueden propagar ransomware a otros sistemas. No pueden explorar sigilosamente la red, buscando datos valiosos para exfiltrarlos. Están atrapados en su lugar como un desventurado ladrón que ha logrado caer por un tragaluz solo para encontrarse en una trampa para osos. Se metieron, pero no van a ninguna parte. Y se ha sonado una alarma.

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

Segmentación de confianza cero de Illumio es una solución de seguridad valiosa para cualquier organización 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 las prácticas de red o seguridad.

Illumio protege las aplicaciones al facilitar que los desarrolladores y los equipos de seguridad definan políticas de Segmentación de Confianza Cero. Una vez creadas, las organizaciones pueden aplicar fácilmente esas políticas utilizando Illumio Nodo de aplicación virtual (VEN) 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 ligero y a prueba de fallas que se puede incluir fácilmente en las compilaciones de software. No se requieren grandes cambios de diseño.

La solución Illumio utiliza firewalls, pero les permite a los desarrolladores la molestia de tener que programar conjuntos complejos de reglas de firewall. En su lugar, permite que los desarrolladores y el equipo de seguridad definan las políticas que quieren que se apliquen, permitiendo que solo el tráfico necesario pase a través de sus aplicaciones y luego enviar esas políticas a los VEN integrados en las aplicaciones para su cumplimiento.

Las organizaciones DevSecOps pueden ajustar las políticas para diversas 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 Estados Unidos

Luego, el equipo de DevSecOps simplemente agrega un Illumio VEN a una compilación de software. Una vez que se ejecuta en el entorno de aplicaciones, el VEN aplica Políticas de confianza cero, genera alertas cuando se detecta un movimiento lateral sospechoso y frenta el tráfico en respuesta a ataques activos, aislando los endpoints infectados del resto de la red.

Illumio también ofrece un Cliente C-VEN y servicio Kubelink para su uso en entornos en contenedores, que son populares en 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 DaemOnset, C-VEN escala hacia arriba y hacia abajo a medida que evoluciona el cluster. Kubelink es un servicio de Illumio que monitorea el servidor API de Kubernetes para aprender sobre los recursos dentro del clúster y proporcionar contexto Kubernetes al PCE. Se entrega como un paquete y requiere solo una réplica por cluster, 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 de seguridad y flujos de trabajo.

El conjunto de productos Illumio proporciona Segmentación de Confianza Cero dondequiera que se implementen aplicaciones y servicios, incluidos endpoints en:

• Centros de datos: Núcleo de Illumio
• 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 las aplicaciones en todas partes, las organizaciones pueden estar preparadas para proteger sus datos, aplicaciones y personas mientras continúa el lento trabajo de escaneo de redes y búsqueda de amenazas.

Para obtener más información:

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