Hola InfoSec, ¿qué estás haciendo para proteger a tu equipo de DevOps?

DevOps, las aplicaciones sin servidor y los contenedores son solo algunos de los últimos avances en el arsenal de herramientas de un desarrollador. Para los equipos de desarrollo, esto significa que el tiempo de comercialización (TTM) es más rápido, especialmente para los equipos ágiles. Entonces, ¿cómo y qué están haciendo los equipos de operaciones de seguridad para garantizar que la seguridad se mantenga al ritmo de este rápido desarrollo? La mayoría está intentando incorporar un ingeniero de seguridad en sus equipos de desarrollo, lo cual es un excelente primer paso, pero existen múltiples capas que se necesitan para garantizar la protección de la organización más allá del código fuente.

DevOps o DevSecOps representa un gran avance, pero su adopción (e implementación) aún resulta difícil para muchas organizaciones. Incluso si una organización ya ha implementado DevSecOps, aún existen importantes preocupaciones que todo equipo de seguridad debe tener en cuenta.

Independientemente del tamaño de la organización, desde una pequeña startup tecnológica hasta una empresa global, una implementación rápida es clave para mantener una ventaja competitiva. La seguridad debe proporcionar los permisos necesarios para que el equipo de desarrollo pueda realizar su trabajo. Tanto los desarrolladores como los equipos de seguridad necesitan poder instalar cualquier herramienta, biblioteca, etc., cuando sea necesario.

Has oído hablar de La NPM está siendo comprometida ¿Cierto? ¿Qué pasa? Arch Linux? Pitón¿Qué controles de seguridad tiene implementados para detectar y prevenir esto en su organización?

Monitorizar todos los entornos

Los equipos de seguridad tienen un gran número de preocupaciones que deben abordarse a diario, desde la posibilidad de que paquetes de terceros se vean comprometidos hasta sus sistemas de producción. Pero ¿qué ocurre con los entornos de implementación? ¿Y los entornos de control de calidad? ¿Los supervisan tan bien como la producción? Deberían.

En muchas situaciones (aunque no necesariamente una buena práctica), un entorno de desarrollo o control de calidad es una duplicación de un entorno conocido como bueno (como producción). Esto significa que este entorno puede tener producción Datos que sus equipos de seguridad deben conocer. Estos entornos de desarrollo deben contar con controles de seguridad iguales o similares a los de sus entornos de producción y deben supervisarse (y registrarse) como cualquier sistema de producción.

Hay muchos otros controles que puedes agregar, pero el punto es que debes asegurarte de que tu equipo esté monitoreando con precisión estos entornos y tenga visibilidad de cualquier cambio realizado en cualquier entorno.

Si sus entornos de desarrollo o control de calidad están repletos de datos que no son de producción, aún existen riesgos que debe tener en cuenta.

¡Claves, tokens, CI/CD, Dios mío!

¿Tienen sus desarrolladores acceso a sus entornos de compilación e implementación de CI/CD (integración y entrega continuas)? ¿Tienen acceso a los entornos de desarrollo, ya sea localmente o en AWS/Azure/GCP, etc.?

Si respondió que sí, debe asegurarse de supervisar de cerca la actividad de sus desarrolladores (especialmente en su sistema local). Basta con visitar un sitio web malicioso o ser víctima de un correo electrónico de phishing para estar en grave peligro.

Si sus desarrolladores acceden a recursos en la nube, suelen usar un conjunto de credenciales o claves de acceso/secretas para acceder a estos entornos. ¿Adivina dónde se almacenan? Sí, en su sistema local. Aquí tiene una lista rápida de lugares donde buscar:

CLI de AWS: ls ~/.aws ~/.aws/credentials ~/.aws/config CLI de Azure: $HOME/.azure (*nix y macOS) %USERPROFILE%\.azure (Windows)

Si estas credenciales en las máquinas de sus desarrolladores se ven comprometidas, podría ser devastador para su organización. Un agente malicioso puede modificar sus entornos de CI/CD y alterar su código base sin ser detectado en los binarios o bibliotecas compilados.

Además, debe evitar que los desarrolladores envíen secretos accidentalmente a los repositorios. Hay varias maneras de detectar esto, pero una de ellas es usar secretos de git de AWS.

Asegúrese de que su equipo de seguridad comprenda dónde se guardan los secretos, cómo se utilizan y cuáles son las consecuencias de no supervisar o alertar sobre el posible uso indebido de estas credenciales.

Contenerización

A medida que las organizaciones migran a contenedores, sin servidor e infraestructura como código, los equipos de seguridad de la información deben colaborar con los equipos de desarrollo para establecer un repositorio interno de contenedores que el equipo de seguridad supervise continuamente. Si se necesita un nuevo paquete o biblioteca, asegúrese de que un ingeniero de seguridad (de su equipo de desarrollo) revise el código antes de integrarlo en su rama maestra. Además, debe comenzar a implementar el análisis automatizado de sus repositorios para identificar posibles secretos ocultos en las confirmaciones y bibliotecas de terceros vulnerables que se importen o utilicen en su producto.

Equipo de desarrollo + seguridad

Imagina que estás en un equipo de desarrollo y alguien de otro departamento llega y te dice que tu trabajo es pésimo y que hay agujeros de seguridad por todas partes. ¿Cómo reaccionarías? Bueno, probablemente no muy bien, sobre todo si crees que tu código es bastante bueno.

Este tipo de interacción con los equipos de desarrollo es constante, y necesitamos abordar este problema de forma diferente. Por eso, necesitamos integrar ingenieros de seguridad en nuestros equipos de desarrollo. Este ingeniero debe ser capaz de identificar problemas de seguridad, crear elementos del backlog (tickets) y trabajar (codificar) dichos elementos. Esta persona clave es tanto desarrollador como especialista en seguridad dentro del equipo de desarrollo.

Ahora, imagina recibir retroalimentación de tu compañero de equipo. La reacción del resto del equipo de desarrollo sería más comprensiva y tendrían una línea de comunicación directa, lo que incluiría construir una relación a largo plazo entre desarrolladores y seguridad. A medida que se sientan cómodos, los demás desarrolladores del equipo no querrán añadir más trabajo a su compañero. Entonces, ¿crees que se tomarán su tiempo o se detendrán a pensar en su implementación? Yo sí.

Además, este ingeniero de seguridad debe participar en las conversaciones con el gerente/propietario del producto y el arquitecto en las primeras etapas, ya que son el personal de seguridad de facto y deben ser parte de las decisiones de diseño iniciales que pueden afectar la forma en que su producto maneja la seguridad (piense en autenticación, secretos compartidos, comunicaciones, etc.)

Envolver

Todos los profesionales de seguridad están ocupados. Hay demasiadas alertas y pocas horas al día. Aunque no podamos responder a todas las alertas, los miembros del equipo del centro de operaciones de seguridad (SOC) deben comprender la misión de su organización, la ubicación de los activos críticos y qué buscar en este panorama de amenazas en constante evolución. Al colaborar con los equipos de desarrollo, podemos ayudar a proteger nuestras respectivas organizaciones y comenzar a integrar la seguridad en nuestro ciclo de vida de desarrollo.