Seguridad en DevOps (DevSecOps)

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

Desafortunadamente, la respuesta es no. DevSecOps es un esfuerzo continuo y continuo que requiere la atención de todos los usuarios en las operaciones de desarrollo y TI. Aunque el trabajo nunca se realiza realmente, las prácticas que los equipos emplean para evitar y controlar las infracciones pueden ayudar a producir sistemas que sean lo más seguros y resistentes posible.

Fundamentalmente, si alguien quiere entrar, entrarán... acéptalo. Lo que decimos a los clientes es: número uno, estás en la lucha, ya sea que lo pensaras o no. Número dos, casi con certeza están siendo infiltrados." -- Michael Hayden, ex director de la NSA y la CIA

La conversación de seguridad

Se recomienda que los equipos que no tengan una estrategia formal de DevSecOps comiencen a planear lo antes posible. Al principio, puede haber resistencia de los miembros del equipo que no aprecian plenamente las amenazas que existen. Es posible que otros no sientan que el equipo está equipado para enfrentar el problema y que cualquier inversión especial sería una distracción desperdiciada de las características de envío. Sin embargo, es necesario comenzar la conversación para crear consenso sobre la naturaleza de los riesgos, cómo el equipo puede mitigarlos y si el equipo necesita recursos que no tienen actualmente.

Espere que los críticos traigan algunos argumentos comunes, como:

• ¿Cómo es real la amenaza? A menudo, los equipos no aprecian el valor potencial de los servicios y los datos que tienen la responsabilidad de proteger.
• Nuestro equipo es bueno, ¿verdad? Una discusión de seguridad puede percibirse como duda en la capacidad del equipo para crear un sistema seguro.
• No creo que sea posible. Este es un argumento común de los ingenieros juniors. Los que tienen experiencia suelen conocer mejor.
• Nunca hemos sido vulnerados. ¿Pero cómo sabes? ¿Cómo lo sabrías ?
• Debates infinitos sobre el valor. DevSecOps es un compromiso serio que puede percibirse como una distracción del trabajo en las características principales. Aunque la inversión en seguridad debe equilibrarse con otras necesidades, no se puede omitir.

El cambio de mentalidad

La cultura de DevSecOps requiere un cambio importante en la mentalidad. No solo es necesario evitar infracciones, sino también asumirlas .

Componentes de estrategia de seguridad

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

Todos los equipos ya deberían tener al menos algunas prácticas vigentes para evitar infracciones. 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 características de pruebas de seguridad.

Sin embargo, muchos equipos carecen de una estrategia que supone que las infracciones del sistema son inevitables. Suponiendo que ha sido vulnerado puede ser difícil de admitir, especialmente cuando tiene conversaciones difíciles con la dirección, pero esa suposición puede ayudarle a responder a preguntas sobre la seguridad cuando tenga tiempo. No quieres descubrirlo todo durante una emergencia de seguridad real.

Entre las preguntas comunes que se deben considerar se incluyen:

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

Procedimientos clave de DevSecOps

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

En primer lugar, céntrese en mejorar el tiempo medio para la detección y el tiempo medio de recuperación. Estas métricas indican cuánto tiempo se tarda en detectar una infracción y cuánto tiempo se tarda en recuperarse, respectivamente. Se pueden rastrear mediante pruebas continuas en sitios en vivo de los planes de respuesta de seguridad. Al evaluar las posibles directivas, mejorar estas métricas debe ser una consideración importante.

Practicar defensa en profundidad. Cuando se produce una infracción, 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 tan lejos, una política de asumir que habrá brechas lleva a los equipos a minimizar la exposición frente a un atacante que ya ha accedido.

Por último, realice evaluaciones periódicas posteriores a la infracción de seguridad de sus prácticas y entornos. Una vez resuelta una infracción, el equipo debe evaluar el rendimiento de las directivas, así como su propio cumplimiento. Las directivas son más eficaces cuando los equipos los siguen realmente. Cada infracción, ya sea real o practicada, debe considerarse una oportunidad para mejorar.

Estrategias para mitigar amenazas

Hay demasiadas amenazas para enumerarlas todas. Algunos agujeros de seguridad se deben a problemas en dependencias como sistemas operativos y bibliotecas, por lo que mantenerlos up-to-date es crítico. Otros se deben a errores en el código del sistema que requieren un análisis cuidadoso para encontrar y corregir. La mala administración secreta es la causa de muchas infracciones, como es la ingeniería social. Es una buena práctica pensar en el tipo diferente de agujeros de seguridad y lo que significan para el sistema.

Vectores de ataque

Considere un escenario en el que un atacante ha obtenido acceso a las credenciales de un desarrollador. ¿Qué pueden hacer?

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

• Almacenar secretos en bóvedas protegidas
• Eliminación de cuentas de administrador local
• Restringir SAMR
• Protector de Credenciales
• Eliminación de servidores de inicio dual
• Suscripciones independientes
• Autenticación multifactor
• Estaciones de trabajo de acceso con privilegios
• Detectar con ATP y Microsoft Defender for Cloud

Administración de secretos

Todos los secretos deben almacenarse 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 bóvedas 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 tiempo de implementación al compilar configuraciones de entorno, mientras que se accede a otras en tiempo de ejecución. Los secretos en tiempo de implementación normalmente requieren una nueva implementación para aplicar la nueva configuración, mientras que los secretos en tiempo de ejecución se acceden cuando sea necesario y se pueden actualizar en cualquier momento.

Las plataformas tienen características de almacenamiento seguras para administrar secretos en canalizaciones de CI/CD y entornos en la nube, como Azure Key Vault y Acciones de GitHub.

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).
• Seguridad avanzada de GitHub 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 la autoridad de seguridad local en Windows. Solo requiere acceso administrativo a la máquina o una cuenta con el privilegio de depuración habilitado.
• 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 participar en ejercicios de juego 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 un atacante. Intentan modelar ataques reales para encontrar brechas en la seguridad. Si pueden aprovechar cualquiera, también muestran el posible impacto de sus infracciones.

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 la situación y medir la preparación y eficacia de la estrategia de DevSecOps.

Evolución 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 explotar problemas. Probablemente será mucho más fácil de lo esperado al principio. Los equipos que no han intentado atacar activamente sus propios sistemas suelen no tener en cuenta el tamaño y la cantidad de agujeros de seguridad disponibles para los atacantes. El equipo azul puede desmoralizarse al principio, ya que serán superados repetidamente. Afortunadamente, el sistema y las prácticas deben evolucionar con el tiempo de manera que el equipo azul gana de forma coherente.

Preparación para juegos de guerra

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

Organización de equipos

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

El equipo rojo debe incluir algunos ingenieros con mente de seguridad y desarrolladores profundamente familiarizados con el código. También resulta útil aumentar el equipo con un especialista en pruebas de penetración, si es posible. Si no hay especialistas internos, muchas empresas proporcionan este servicio junto con la mentoría.

El equipo azul debe estar formado por ingenieros de operaciones que tengan un profundo conocimiento de los sistemas y el registro disponibles. Tienen la mejor posibilidad de detectar y abordar el comportamiento sospechoso.

Realizar juegos de guerra tempranos

Espera que el equipo rojo sea efectivo en los primeros juegos de guerra. Los atacantes deberían poder tener éxito mediante ataques bastante simples, como encontrar secretos mal protegidos, la inyección de código SQL y campañas de suplantación de identidad exitosas. Dedique mucho tiempo entre las rondas a aplicar correcciones y comentarios sobre las directivas. Esto variará según la organización, pero no quieres iniciar la siguiente ronda hasta que todos estén seguros de que la ronda anterior se ha aprovechado al máximo.

Juegos de guerra en curso

Después de unas pocas rondas, el equipo rojo tendrá que confiar en técnicas más sofisticadas, como scripting entre sitios (XSS), exploits de deserialización y vulnerabilidades de sistemas de ingeniería. La incorporación de expertos externos a la seguridad en áreas como Active Directory puede resultar útil para atacar vulnerabilidades de seguridad más oscuras. En este momento, 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 a la vulneración.

Los defensores piensan en listas. Los atacantes piensan en gráficos. Siempre que esto sea cierto, los atacantes ganan". -- John Lambert (MSTIC)

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

Guidelines

Los juegos de guerra no deberían ser gratis 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 usado por Microsoft:

1. Los equipos rojo y azul no harán daño. Si la posibilidad de causar daños es significativa, debe documentarse y abordarse.
2. El equipo rojo no debe comprometer más de lo necesario para capturar los activos de destino.
3. Las reglas de 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 distintivos falsos, hostigar a las personas, etc.
4. Si un ataque de ingeniería social es exitoso, no revele el nombre de la persona que se vio comprometida. La lección se puede compartir sin alienar o vergonzar a un miembro del equipo con el que todos los usuarios necesitan seguir trabajando.

Reglas de compromiso

Estas son las reglas de ejemplo de involucración usadas por Microsoft:

1. No afecte a la disponibilidad de ningún sistema.
2. No acceda a los datos externos del cliente.
3. No debilite significativamente las protecciones de seguridad actualmente implementadas en ningún servicio.
4. No realice acciones destructivas intencionadamente contra ningún recurso.
5. Proteja las credenciales, las vulnerabilidades y otra información crítica obtenida.

Resultados

Cualquier riesgo de seguridad o lección aprendida debe documentarse en un registro de tareas de reparación. Teams debe definir un acuerdo de nivel de servicio (SLA) para abordar los riesgos de seguridad rápidamente. Los riesgos graves deben abordarse lo antes posible, mientras que los problemas menores pueden tener una fecha límite de dos sprints.

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

Lecciones aprendidas en Microsoft

Microsoft practica regularmente juegos de guerra y ha aprendido muchas lecciones a lo largo del camino.

• Los juegos de guerra son una manera eficaz de cambiar la cultura de DevSecOps y tener presente 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 de producción y necesitando autenticación en dos fases.
• El control del sistema de ingeniería conduce al control de 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 sea más difícil para los atacantes. Cada límite que tienen que romper los ralentiza y ofrece otra oportunidad para atraparlos.
• Nunca cruce dominios de confianza. La producción nunca debe confiar en nada en el entorno de prueba.

Pasos siguientes

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