Seguridad en DevOps (DevSecOps)

La seguridad es una parte clave de DevOps. ¿Pero cómo sabe un equipo si un sistema es seguro? ¿Es de verdad posible ofrecer un servicio completamente seguro?

Por desgracia, la respuesta es no. DevSecOps es un trabajo continuo y siempre en marcha que requiere la atención de todos los usuarios en las operaciones de desarrollo y TI. Aunque no se termina nada como tal, los procedimientos que los equipos emplean para evitar y controlar las filtraciones y ataques pueden ayudar a producir sistemas que sean lo más seguros y resistentes posible.

“Básicamente, si alguien quiere entrar, va a entrar... Hay que aceptar eso. Esto es lo que les decimos a los clientes es: primero, que la batalla nunca cesa, aunque creyera que no. Y segundo, casi seguramente ya haya sufrido algún ataque”. -- Michael Hayden, exdirector de la NSA y la CIA

La conversación sobre seguridad

Se recomienda a los equipos que no tengan una estrategia formal de DevSecOps para empezar la planificación lo antes posible. Al principio, es posible que haya cierta resistencia de los miembros del equipo que no aprecian plenamente las amenazas existentes. Es posible que otros no sientan que el equipo está preparado para afrontar el problema y que cualquier inversión especial será una distracción desperdiciada con respecto al envío de funciones. Pero es necesario comenzar la conversación para crear consenso sobre la naturaleza de los riesgos, cómo el equipo puede mitigarlos y si necesita recursos que no tiene actualmente.

Espere que los escépticos aporten algunos argumentos comunes, como los siguientes:

• ¿Qué credibilidad tiene la amenaza? Los equipos a menudo no aprecian el valor potencial de los servicios y los datos que les han encargado proteger.
• Nuestro equipo es bueno, ¿verdad? Hablar sobre un tema de seguridad puede percibirse como una duda sobre la capacidad del equipo para crear un sistema seguro.
• No creo que sea posible. Este es un argumento común de los ingenieros junior. Los que tienen experiencia conocen la realidad.
• Nunca hemos sufrido una vulneración de seguridad. Pero, ¿cómo lo saben? ¿Cómo podrían saberlo?
• Debates sin fin sobre el valor. DevSecOps es un compromiso serio que puede percibirse como una distracción con respecto al trabajo en funciones principales. Aunque la inversión en seguridad se debe equilibrar con otras necesidades, no se puede ignorar.

El cambio de mentalidad

La cultura de DevSecOps requiere un cambio importante en la mentalidad. No solo es necesario evitar ataques y filtraciones, sino también asumirlos.

Componentes de estrategia de seguridad

Hay muchas técnicas que se pueden aplicar en la búsqueda de sistemas más seguros.

Prevención de infracciones	Suposición de infracciones
Modelos de amenazas	Ejercicios de juego de guerra
Revisiones de código	Monitores de seguridad central
Pruebas de seguridad	Pruebas de penetración de sitios en directo
Ciclo de vida del desarrollo de seguridad (SDL)

Todos los equipos ya deben haber tenido al menos algunos procedimientos claros para evitar ataques y filtraciones. La escritura de código seguro se ha vuelto más predeterminada y hay muchas herramientas gratuitas y comerciales para ayudar en el análisis estático y otras funciones de pruebas de seguridad.

Sin embargo, muchos equipos carecen de una estrategia que dé por hecho que los ataques y filtraciones del sistema son inevitables. Aceptar que se ha recibido un ataque puede ser algo difícil de admitir, especialmente cuando surgen conflictos con los responsables, pero esa suposición puede ayudarle a responder preguntas sobre la seguridad por su cuenta. No hay que saberlo todo durante una situación de vulneración de seguridad real.

Entre las preguntas comunes que hay que plantearse se incluyen:

• ¿Cómo se detecta un ataque?
• ¿Cómo responderá si hay un ataque o penetración?
• ¿Cómo se puede recuperar de un ataque, como cuando se hayan filtrado o manipulado los datos?

Procedimientos clave de DevSecOps

Hay varias procedimientos comunes de DevSecOps que se aplican a prácticamente cualquier equipo.

En primer lugar, se deben centrar en mejorar el tiempo medio de detección y el tiempo medio de recuperación. Estos parámetros indican cuánto tiempo se tarda en detectar un ataque y cuánto tiempo se tarda en recuperarse, respectivamente. Se puede hacer un seguimiento a través de pruebas continuas del sitio activo de los planes de respuesta de seguridad. Al evaluar las posibles directrices, la misión de mejorar estos parámetros se debe tener especialmente en cuenta.

Defina un sistema de defensa en profundidad. Cuando surja un ataque, los atacantes pueden acceder a las redes internas y a todo lo que hay dentro de ellas. Aunque sería ideal detener a los atacantes antes de que lleguen más lejos, si se establece una directriz en la que se asuma los ataques incitaría a los equipos a minimizar la exposición de un atacante que ya haya entrado.

Por último, realice evaluaciones periódicas posteriores al ataque de sus procedimientos y entornos. Una vez salvado el ataque, el equipo debe evaluar el rendimiento de las directrices, así como su propio cumplimiento. Las directrices son más eficaces cuando los equipos las siguen fielmente. Cada ataque, ya sea real o ejercido, debe considerarse una oportunidad para mejorar.

Estrategias para mitigar amenazas

Hay demasiadas amenazas para nombrarlas todas. Algunas vulnerabilidades de seguridad se deben a problemas en dependencias como sistemas operativos y bibliotecas, por lo que mantenerlas actualizadas es crítico. Otros se deben a errores en el código del sistema que requieren un análisis cuidadoso para encontrarlos y corregirlos. La mala administración secreta es la causa de muchas infracciones, como la ingeniería social. Es bueno pensar en los diferentes tipos de brechas de seguridad y lo que significan para el sistema.

Vectores de ataque

Piense en una situación en la que un atacante ha obtenido acceso a las credenciales de un desarrollador. ¿Qué podría hacer?

Privilegio	Tráfico
¿Podría enviar correos electrónicos?	Amigos del phishing
¿Podría acceder a otras máquinas?	Iniciar sesión, mimikatz, repetir
¿Podría modificar la fuente?	Insertar código
¿Podría modificar el proceso de compilación o de creación de versiones?	Insertar código, ejecutar scripts
¿Podría acceder a un entorno de prueba?	Si un entorno de producción toma una dependencia en el entorno de prueba, hay que aprovecharlo
¿Podría acceder al entorno de producción?	Son tantas las opciones...

¿Cómo puede su equipo defenderse contra estos ataques?

• Almacenamiento de secretos en almacenes protegidos
• Eliminación de cuentas de administrador local
• Restricción de SAMR
• Credential Guard
• Eliminación de servidores de base dual
• Suscripciones independientes
• Autenticación multifactor
• Estaciones de trabajo con privilegios de acceso
• Método de detección con ATP & Microsoft Defender for Cloud

Administración de secretos

Todos los secretos se deben almacenar en un almacén protegido. Los secretos incluyen:

• Contraseñas, claves y tokens
• Claves de cuenta de almacenamiento
• Certificados
• Credenciales usadas en entornos que no son de producción compartidos también

Debe usar una jerarquía de almacenes para eliminar la duplicación de secretos. Tenga en cuenta también cómo y cuándo se accede a los secretos. Algunos se usan en fase de implementación al compilar configuraciones de entorno, mientras que se accede a otros en tiempo de ejecución. Normalmente, los secretos en fase de implementación necesitan de una nueva implementación para seleccionar la nueva configuración, mientras que se accede a los secretos en tiempo de ejecución cuando es necesario y se pueden actualizar en cualquier momento.

Las plataformas cuentan con funciones de almacenamiento seguras para administrar secretos en procesos de CI/CD y entornos en la nube, como Azure Key Vault y GitHub Actions.

Herramientas útiles

• Microsoft Defender for Cloud es ideal para alertas de infraestructura genéricas, como malware, procesos sospechosos, etc.
• Herramientas de análisis de código fuente para pruebas estáticas de seguridad de aplicaciones (SAST).
• GitHub advanced security para el análisis y la supervisión de repositorios.
• mimikatz extrae contraseñas, claves, códigos pin, tickets y mucho más de la memoria de lsass.exe, el Servicio de subsistema de autoridad de seguridad local en Windows. Solo se exige acceso administrativo a la máquina o una cuenta con privilegios de depuración activados.
• BloodHound crea un gráfico de las relaciones dentro de un entorno de Active Directory. Se puede usar el equipo rojo para identificar fácilmente vectores de ataque que son difíciles de identificar rápidamente.

Ejercicios de juego de guerra

Una práctica común en Microsoft es llevar a cabo ejercicios de juegos de guerra. Estos son eventos de prueba de seguridad en los que dos equipos se encargan de probar la seguridad y las directivas de un sistema.

El equipo rojo asume el rol de atacante. Intentan simular ataques reales para detectar brechas en la seguridad. Si pueden traspasar alguna barrera, también demuestran el posible impacto de sus ataques.

El equipo azul asume el rol del equipo de DevOps. Prueban su capacidad de detectar y responder a los ataques del equipo rojo. Esto ayuda a mejorar el conocimiento de cada situación y evaluar la preparación y eficacia de la estrategia de DevSecOps.

Progreso de una estrategia de juegos de guerra

Los juegos de guerra son eficaces para reforzar la seguridad porque motivan al equipo rojo a encontrar y poner a prueba problemas. Probablemente sea mucho más fácil de lo esperado al principio. Los equipos que no han intentado atacar activamente sus propios sistemas no suelen tener en cuenta el tamaño y la cantidad de brechas de seguridad a disposición de los atacantes. El equipo azul puede desmoralizarse al principio, ya que volverán a sufrir los ataques repetidas veces. Afortunadamente, el sistema y los procedimientos deben evolucionar con el tiempo de manera que el equipo azul pueda salir vencedor consecuentemente.

Preparación de los juegos de guerra

Antes de comenzar los juegos de guerra, el equipo debe ocuparse de cualquier problema que pueda encontrar a través de un pase de seguridad. Este es un gran ejercicio para realizar antes de intentar lanzar un ataque, ya que aportará una experiencia base para que todos los usuarios comparen con la situación después de detectar la primera vulnerabilidad más adelante. Empiece por identificar vulnerabilidades mediante una revisión manual del código y el uso de herramientas de análisis estático.

Organizar equipos

Los equipos rojos y azules deben organizarse por especialidad. El objetivo es crear los equipos más capaces en cada ámbito lado con el fin de ejecutar las operaciones lo más eficazmente posible.

El equipo rojo debe estar formado por algunos ingenieros orientados a la seguridad y desarrolladores que estén muy familiarizados con el código. También resulta útil integrar en el equipo a un especialista en pruebas de penetración, si es posible. Si no hay especialistas internos, muchas empresas prestan este servicio junto con la mentoría.

El equipo azul debe estar formado por ingenieros de operaciones que conozcan muy bien los sistemas y registros disponibles. Estos tienen más posibilidades de detectar y neutralizar la actividad sospechosa.

Ejecución de los primeros juegos de guerra

Se debe esperar que el equipo rojo sea efectivo en los primeros juegos de guerra. Deben poder realizarse correctamente a través de ataques bastante simples, como encontrar secretos mal protegidos, inserción de código SQL y campañas de suplantación de identidad eficaces. Dedique mucho tiempo entre sesiones a aplicar correcciones y dejar comentarios sobre las directrices. Esto puede variar según la organización, pero no es recomendable empezar la siguiente sesión hasta que todos estén seguros de que la anterior se ha explotado todo lo posible y aconsejable.

Desarrollo de los juegos de guerra

Tras unas sesiones, el equipo rojo tendrá que confiar en técnicas más sofisticadas, como scripts de sitios (XSS), ataques de deserialización y vulnerabilidades del sistema de ingeniería. La incorporación de expertos externos en seguridad en áreas como Active Directory puede resultar útil para contrarrestar vulnerabilidades de seguridad poco conocidas. En este punto, el equipo azul no solo debe tener una plataforma protegida para defender, sino que también usará el registro completo y centralizado para los análisis forenses posteriores al ataque.

“Los defensores piensan en listas. Los atacantes piensan en gráficas. Siempre que esto se dé, los atacantes siempre ganan”. -- John Lambert (MSTIC)

Si pasa mucho tiempo, el equipo rojo tardará mucho más en alcanzar los objetivos. Cuando lo hacen, a menudo se necesita la detección y encadenamiento de varias vulnerabilidades para tener un impacto limitado. A través del uso de herramientas de control en tiempo real, el equipo azul debe empezar a detectar posibles ataques en tiempo real.

Directrices

Los juegos de guerra no deberían ser una barra libre para todos. Es importante reconocer que el objetivo es generar un sistema más eficaz ejecutado por un equipo más eficaz.

Código de conducta

Este es un código de conducta de ejemplo que se practica en Microsoft:

1. Los equipos rojo y azul no harán ningún daño. Si la posibilidad de causar daños es significativa, debe documentarse y resolverse.
2. El equipo rojo no debe poner en peligro más de lo necesario para capturar los recursos de destino.
3. Las reglas del sentido común se aplican a los ataques físicos. Aunque se anima al equipo rojo a ser creativo con ataques no técnicos, como la ingeniería social, no deben imprimir credenciales falsas, hostigar a las personas, etc.
4. Si un ataque de ingeniería social tiene éxito, no revele el nombre de la persona que se ha visto involucrada. La lección se puede compartir sin alienar o avergonzar a un miembro del equipo con el que todos los usuarios necesitan seguir trabajando.

Reglas de juego

Estas son ejemplos de reglas del juego usadas por Microsoft:

1. No afectar a la disponibilidad de ningún sistema.
2. No acceder a datos externos del cliente.
3. No debilitar significativamente las medidas de seguridad en ningún servicio.
4. No realizar intencionadamente intervenciones destructivas contra ningún recurso.
5. Proteger credenciales, vulnerabilidades y otra información crítica obtenida.

Resultados

Los riesgos de seguridad o las experiencias aprendidas deben documentarse en un trabajo pendiente de elementos de reparación. Los equipos deben definir un acuerdo de nivel de servicio (SLA) para responder a los riesgos de seguridad rápidamente. Los riesgos graves deben subsanarse lo antes posible, mientras que los problemas menores pueden tener un plazo límite de dos sprints.

Se debe presentar un informe a toda la organización con las experiencias aprendidas y las vulnerabilidades detectadas. Es una oportunidad de aprendizaje para todos los usuarios, así que hay que aprovecharlo.

Experiencias aprendidas en Microsoft

Cada cierto tiempo, Microsoft poner en marcha juegos de guerra y ha sacado muchas conclusiones y experiencias durante todo este tiempo.

• Los juegos de guerra son una manera eficaz de cambiar la cultura de DevSecOps y tener como prioridad la seguridad.
• Los ataques de suplantación de identidad (phishing) son muy eficaces para los atacantes y no deben ser subestimados. El impacto se puede contener limitando el acceso a la fase de producción y mediante autenticación de dos factores.
• El control del sistema de ingeniería lleva a poder controlar todo. Asegúrese de controlar estrictamente el acceso al agente de compilación o versión, la cola, el grupo y la definición.
• Practique la defensa en profundidad para que los atacantes lo tengan más difícil. Cada barrera que tengan que sobrepasar los ralentiza y da otra oportunidad para atraparlos.
• Nunca cruce dominios de confianza. El equipo de producción nunca debe confiar en nada en la prueba.

Pasos siguientes

Obtenga más información sobre el ciclo de vida del desarrollo de la seguridad y DevSecOps en Azure.