¿Los riesgos de la cadena de suministro lo deprimieron? ¡Mantenga la calma y sea estratégico!

La industria de la seguridad colectivamente pierde la cabeza cuando se descubren nuevas vulnerabilidades en el software. OpenSSL no es una excepción, y dos nuevas vulnerabilidades abrumaron las fuentes de noticias a fines de octubre y principios de noviembre de 2022. El descubrimiento y la divulgación son solo el comienzo de este ciclo interminable de vulnerabilidades. Las organizaciones afectadas se enfrentan a la remediación, que es especialmente dolorosa para quienes están en la primera línea de TI. Los líderes de seguridad deben mantener una estrategia de seguridad cibernética efectiva para ayudar a filtrar parte del ruido sobre nuevas vulnerabilidades, reconocer los impactos en las cadenas de suministro y proteger sus activos en consecuencia.

Los ataques a la cadena de suministro no van a desaparecer

En aproximadamente un año, hemos sufrido graves vulnerabilidades en los componentes, incluidos log4j, Marco de primaveray OpenSSL. La explotación de vulnerabilidades más antiguas tampoco cesa en implementaciones que están mal configuradas o que usan dependencias vulnerables conocidas. En noviembre de 2022, el público se enteró de un campaña de ataque contra el Poder Ejecutivo Federal Civil (FCEB), atribuible a una amenaza iraní patrocinada por el estado. Esta entidad federal de EE. UU. ejecutaba la infraestructura VMware Horizon que contenía la vulnerabilidad Log4Shell, que sirvió como vector de ataque inicial. FCEB se vio afectado por una cadena de ataque compleja que incluía movimiento lateral, compromiso de credenciales, compromiso del sistema, persistencia de la red, elusión de la protección de puntos finales y cryptojacking.

Las organizaciones pueden preguntarse "¿por qué consumir OSS?" después de incidentes de seguridad de paquetes vulnerables como OpenSSL o Log4j. Los ataques a la cadena de suministro continúan aumentando porque la reutilización de componentes tiene "buen sentido comercial" para socios y proveedores. Diseñamos sistemas reutilizando el código existente en lugar de construir desde cero. Esto es para reducir el esfuerzo de ingeniería, escalar operativamente y entregar rápidamente. El software de código abierto (OSS) generalmente se considera confiable en virtud del escrutinio público que recibe. Sin embargo, el software cambia constantemente y surgen problemas debido a errores de codificación o dependencias vinculadas. También se descubren nuevos problemas a través de la evolución de las técnicas de prueba y explotación.

Abordar las vulnerabilidades de la cadena de suministro

Las organizaciones necesitan herramientas y procesos apropiados para asegurar diseños modernos. Los enfoques tradicionales, como la gestión de vulnerabilidades o las evaluaciones puntuales, por sí solos, no pueden mantenerse al día. Es posible que las regulaciones aún permitan estos enfoques, lo que perpetúa la división entre "seguro" y "cumplimiento". La mayoría de las organizaciones aspiran a obtener algún nivel de madurez DevOps. "Continuo" y "automatizado" son rasgos comunes de las prácticas de DevOps. Los procesos de seguridad no deberían diferir. Los líderes de seguridad deben mantener el enfoque durante las fases de construcción, entrega y tiempo de ejecución como parte de su estrategia de seguridad:

• Exploración continua en CI/CD: Trate de proteger las canalizaciones de compilación (es decir, shift-left) pero reconozca que no podrá escanear todo el código y el código anidado. El éxito con los enfoques de desplazamiento a la izquierda está limitado por la eficacia del escáner, la correlación de la salida del escáner, la automatización de las decisiones de lanzamiento y la finalización del escáner dentro de las ventanas de lanzamiento. Las herramientas deberían ayudar a priorizar el riesgo de los hallazgos. No todos los hallazgos son procesables y es posible que las vulnerabilidades no se puedan explotar en su arquitectura.

• Escaneo continuo durante la entrega: Ocurren compromisos de componentes y derivas ambientales. Las aplicaciones, la infraestructura y las cargas de trabajo deben escanearse mientras se entregan en caso de que algo se haya comprometido en la cadena de suministro digital cuando se obtienen de registros o repositorios y se inician.

• Exploración continua en tiempo de ejecución: La seguridad en tiempo de ejecución es el punto de partida de muchos programas de seguridad, y el monitoreo de seguridad respalda la mayoría de los esfuerzos de seguridad cibernética. Sin embargo, necesita mecanismos que puedan recopilar y correlacionar la telemetría en todo tipo de entornos, incluidos los entornos de nube, contenedores y Kubernetes. La información recopilada en el tiempo de ejecución debe retroalimentar las etapas anteriores de creación y entrega. Interacciones de identidad y servicio

• Priorice las vulnerabilidades expuestas en tiempo de ejecución: Todas las organizaciones luchan por tener suficiente tiempo y recursos para escanear y arreglar todo. La priorización basada en el riesgo es fundamental para el trabajo del programa de seguridad. La exposición a Internet es solo un factor. Otro es la gravedad de la vulnerabilidad, y las organizaciones a menudo se enfocan en problemas de gravedad alta y crítica, ya que se considera que tienen el mayor impacto. Este enfoque aún puede desperdiciar ciclos de ingeniería y equipos de seguridad porque pueden estar persiguiendo vulnerabilidades que nunca se cargan en el tiempo de ejecución y que no son explotables. Utilice la inteligencia de tiempo de ejecución para verificar qué paquetes se cargan realmente en las aplicaciones y la infraestructura en ejecución para conocer el riesgo de seguridad real para su organización.

Hemos creado orientación específica del producto para guiar a los clientes a través de la reciente locura de OpenSSL.

La última vulnerabilidad de OpenSSL y Log4Shell nos recuerdan la necesidad de estar preparados para la seguridad cibernética y una estrategia de seguridad efectiva. Debemos recordar que los CVE-ID son solo esos problemas conocidos en el software o hardware público. Muchas vulnerabilidades no se informan, en particular las debilidades en el código desarrollado internamente o las configuraciones incorrectas del entorno. Su estrategia de ciberseguridad debe tener en cuenta tecnología distribuida y diversa de diseños modernos. Necesita un programa de gestión de vulnerabilidades modernizado que utilice conocimientos de tiempo de ejecución para priorizar el trabajo de reparación para los equipos de ingeniería. También necesita capacidades de respuesta y detección de amenazas que correlacionen señales entre entornos para evitar sorpresas.

Sobre la autora

Michael Isbitski, Director de Estrategia de Ciberseguridad en Sysdig, ha investigado y asesorado sobre ciberseguridad durante más de cinco años. Tiene experiencia en seguridad en la nube, seguridad de contenedores, seguridad de Kubernetes, seguridad de API, pruebas de seguridad, seguridad móvil, protección de aplicaciones y entrega continua segura. Ha guiado a innumerables organizaciones a nivel mundial en sus iniciativas de seguridad y apoyando sus negocios.

Antes de su experiencia en investigación y asesoramiento, Mike aprendió muchas lecciones duras en la primera línea de TI con más de 20 años de experiencia profesional y de liderazgo centrada en la seguridad de las aplicaciones, la gestión de vulnerabilidades, la arquitectura empresarial y la ingeniería de sistemas.