Posición de seguridad del entorno de DevOps

Completado

Con un aumento de los ataques cibernéticos en sistemas de administración de código fuente y canalizaciones de integración continua y entrega continua, proteger las plataformas DevOps contra la amplia gama de amenazas identificadas en la matriz de amenazas de DevOps es fundamental. Estos ataques cibernéticos pueden permitir la inyección de código, la elevación de privilegios y la filtración de datos, lo que podría provocar un gran impacto.

La administración de la posición de DevOps es una característica de Microsoft Defender for Cloud que:

• Proporciona información sobre la posición de seguridad de todo el ciclo de vida de la cadena de suministro de software.
• Usa escáneres avanzados para evaluaciones detalladas.
• Trata varios recursos, desde organizaciones, canalizaciones y repositorios.
• Permite a los clientes reducir su superficie expuesta a ataques al descubrir las recomendaciones proporcionadas e implementarlas.

Escáneres de DevOps

Para proporcionar conclusiones, la administración de la posición de DevOps usa escáneres de DevOps. Con ellos, se identifican puntos débiles en la administración de código fuente y canalizaciones de integración y entrega continuas mediante la ejecución de comprobaciones en las configuraciones de seguridad y los controles de acceso.

Los escáneres de Azure DevOps y GitHub se usan internamente en Microsoft para identificar los riesgos asociados a los recursos de DevOps, reducir la superficie expuesta a ataques y reforzar los sistemas de DevOps corporativos.

Una vez conectado un entorno de DevOps, Defender for Cloud configura automáticamente estos escáneres para realizar exámenes periódicos cada 24 horas en varios recursos de DevOps, entre los que se incluyen:

• Compilaciones
  
• Archivos seguros
• Grupos de variables
• Conexiones de servicio
• Las organizaciones
• Repositorios

Reducción de riesgos de la matriz de amenazas de DevOps

La administración de la posición de DevOps ayuda a las organizaciones a detectar y corregir errores de configuración perjudiciales en la plataforma de DevOps. Esto conduce a un entorno de DevOps resistente y de confianza cero, que se refuerza frente a una serie de amenazas definidas en la matriz de amenazas de DevOps. Los controles de administración de posturas principales incluyen:

• Acceso secreto con ámbito: minimice la exposición de información confidencial y reduzca el riesgo de accesos no autorizados, pérdidas de datos y movimientos laterales al garantizar que cada canalización solo tenga acceso a los secretos esenciales para su función.
  
• Restricción de ejecutores autohospedados y permisos elevados: restrinja los ejecutores autohospedados y asegúrese de que los permisos de canalización tengan como valor predeterminado solo lectura para evitar ejecuciones no autorizadas y posibles escalaciones.
  
• Protección mejorada de ramas: mantenga la integridad del código al aplicar reglas de protección de rama y evitar inyecciones de código malintencionadas.
  
• Permisos optimizados y repositorios seguros: Reduzca el riesgo de acceso no autorizado y modificaciones mediante el seguimiento de los permisos base mínimos y la habilitación de la protección secreta contra el envío de cambios en os repositorios.
  

Matriz de amenazas de DevOps

Nuestro objetivo al desarrollar la matriz de amenazas para DevOps es crear una base de conocimiento completa que los defensores puedan usar para realizar un seguimiento y crear defensas contra técnicas de ataque relevantes. Con el marco MITRE ATT&CK como base, recopilamos técnicas y vectores de ataque asociados a entornos de DevOps y creamos una matriz dedicada a los métodos de ataque de DevOps.

Cabe destacar que las tácticas de esta matriz deben examinarse desde la perspectiva de DevOps. Por ejemplo, las técnicas de ejecución de una máquina virtual que ejecuta Windows o Linux son diferentes de la ejecución en una canalización de DevOps. En el caso de Linux, la ejecución significa ejecutar código en el sistema operativo. Cuando hablamos de entornos de DevOps, significa ejecutar código en la canalización o en los recursos de DevOps. Además de usar esta matriz de amenazas para clasificar los ataques y los métodos de defensa correspondientes, los defensores pueden trabajar junto con los equipos rojos para probar continuamente las suposiciones y encontrar nuevas técnicas de ataque potenciales.

MITRE ATT&CK definido

La matriz de MITRE ATT&CK es una knowledge base de acceso público donde se explican diversas tácticas y técnicas que usan los atacantes durante un ciberataque.

La knowledge base se organiza en varias categorías: ataque previo, acceso inicial, ejecución, persistencia, elevación de privilegios, evasión defensiva, acceso con credenciales, detección, desplazamiento lateral, recopilación, filtración y comando y control.

Las tácticas (T) representan el "por qué" de una técnica o subtécnica de ATT&CK. Es el objetivo táctico del adversario: el motivo para realizar una acción. Por ejemplo, puede que un adversario quiera obtener acceso a las credenciales.

Las técnicas (T) representan "cómo" un adversario logra un objetivo táctico mediante la realización de una acción. Por ejemplo, un adversario puede volcar credenciales para lograr el acceso a estas.

Common Knowledge (CK) en ATT&CK se refiere al conocimiento común, básicamente, a la forma de actuar documentada de las tácticas y técnicas que ejecutan los adversarios.

Acceso inicial

La táctica de acceso inicial hace referencia a técnicas que un atacante puede usar para obtener acceso a los recursos de DevOps: repositorios, canalizaciones y dependencias. Las técnicas siguientes pueden ser una condición previa para los pasos siguientes:

Autenticación en la Administración de código fuente (SCM): se accede con un método de autenticación a la administración de código fuente de la organización. Puede ser un token de acceso personal (PAT), una clave SSH o cualquier otra credencial de autenticación permitida. Un ejemplo de un método que un atacante puede usar para lograr esta técnica es usar un ataque de suplantación de identidad contra una organización.

Autenticación del servicio de integración continua (CI) y entrega continua (CD): similar a la autenticación en la SCM, un atacante puede aprovechar la autenticación en el servicio CI/CD para atacar DevOps de la organización.

Repositorios públicos de la organización: se accede a los repositorios públicos de la organización que están configurados con funcionalidades de CI/CD. En función de la configuración de la organización, estos repositorios pueden tener la capacidad de desencadenar una ejecución de canalización después de crear una solicitud de incorporación de cambios (PR).

Peligro del punto de conexión: con una vulneración existente, un atacante puede aprovechar la estación de trabajo del desarrollador en peligro, obteniendo así acceso a la SCM, el registro o cualquier otro recurso al que el desarrollador tenga acceso.

Webhooks configurados: cuando una organización tiene configurado un webhook, un atacante podría usarlo como método de acceso inicial en la red de la organización al usar la SCM para desencadenar solicitudes en esa red. Esto podría conceder al atacante acceso a los servicios que no están diseñados para exponerse públicamente o que ejecutan versiones de software antiguas y vulnerables dentro de la red privada.

Ejecución

La táctica de ejecución hace referencia a técnicas que puede usar un adversario malintencionado para obtener acceso de ejecución en los recursos de canalización: la propia canalización o los recursos de implementación. Algunas técnicas de esta sección contienen explicaciones sobre las distintas formas de realizarlas, o lo que llamamos subtécnicas:

Ejecución de canalización envenenada (PPE): hace referencia a una técnica en la que un atacante puede insertar código en el repositorio de una organización, lo que da lugar a la ejecución de código en el sistema de CI/CD del repositorio. Hay diferentes subtécnicas para lograr la ejecución de código:

• PPE directa (d-PPE): casos en los que el atacante puede modificar directamente el archivo de configuración dentro del repositorio. Dado que la canalización la desencadena una nueva solicitud de incorporación de cambios y se ejecuta según el archivo de configuración, el atacante puede insertar comandos malintencionados en el archivo de configuración y estos comandos se ejecutan en la canalización.
  
• PPE indirecto (i-PPE): casos en los que el atacante no puede cambiar directamente los archivos de configuración o en los que estos cambios no se tienen en cuenta cuando se desencadenan. En estos casos, el atacante puede infectar scripts usados por la canalización para ejecutar código, por ejemplo, make-files, test scripts, build scripts, etc.
• PPE público: casos en los que un proyecto de código abierto desencadena la canalización. En estos casos, el atacante puede usar d-PPE o i-PPE en el repositorio público para infectar la canalización.

Manipulación de dependencias: hace referencia a una técnica en la que un atacante puede ejecutar código en el entorno de DevOps o en el entorno de producción mediante la inserción de código malintencionado en las dependencias de un repositorio. Por tanto, cuando se descarga la dependencia, se ejecuta el código malintencionado. Algunas subtécnicas que se pueden usar para lograr la ejecución de código incluyen:

• Confusión o sustitución de dependencias públicas: técnica en la que el adversario publica paquetes malintencionados públicos con el mismo nombre que los paquetes privados. En este caso, dado que la búsqueda de paquetes en mecanismos de control de paquetes normalmente busca primero en registros públicos, se descarga el paquete malintencionado.
• Secuestro de paquete público ("repo-jacking"): secuestro de un paquete público tomando el control de la cuenta del curador, por ejemplo, aprovechando la característica de cambio de nombre de usuario de GitHub.
• Allanamiento de error tipográfico: publicación de paquetes malintencionados con nombres similares a los paquetes públicos conocidos. De este modo, un atacante puede confundir a los usuarios para descargar el paquete malintencionado en lugar del deseado.

Vulneración de los recursos de DevOps: las canalizaciones son, en esencia, un conjunto de recursos de proceso que ejecutan los agentes de CI/CD, junto con otro software. Un atacante puede dirigirse a estos recursos aprovechando una vulnerabilidad en el sistema operativo, el código del agente, otro software instalado en las máquinas virtuales u otros dispositivos de la red para obtener acceso a la canalización.

Control del registro común: un atacante puede obtener el control de un registro usado por la organización, lo que da lugar a imágenes malintencionadas o paquetes ejecutados por las máquinas virtuales de canalización o las máquinas virtuales de producción.

Persistencia

La táctica de persistencia consta de diferentes técnicas que un atacante puede usar para mantener el acceso a un entorno víctima:

Cambios en el repositorio: los adversarios pueden usar los tokens automáticos desde dentro de la canalización para acceder al repositorio e insertar código (suponiendo que el token automático tenga permisos suficientes para hacerlo). Pueden lograr persistencia de esta manera mediante varias subtécnicas:

• Cambio o adición de scripts en el código: es posible cambiar algunos de los scripts de inicialización o agregar nuevos scripts; por tanto, los atacantes descargan una puerta trasera o un iniciador para su uso, por lo que cada vez que la canalización ejecuta estos scripts, también se ejecutará el código del atacante.
  
• Cambio de la configuración de canalización: es posible agregar nuevos pasos en la canalización para descargar un script controlado por el atacante a la canalización antes de continuar con el proceso de compilación.
• Cambio de configuración de las ubicaciones de dependencias: para usar paquetes controlados por atacantes.

Inserción en artefactos: algunos entornos de CI tienen la funcionalidad de crear artefactos que se comparten entre distintas ejecuciones de canalización. Por ejemplo, en GitHub, podemos almacenar artefactos y descargarlos mediante una acción de GitHub desde la configuración de la canalización.

Modificación de imágenes en el Registro: en los casos en los que las canalizaciones tienen permisos para acceder al registro de imágenes (por ejemplo, para escribir imágenes en el registro una vez finalizada la compilación), el atacante podría modificar y plantar imágenes malintencionadas en el registro, lo que seguiría ejecutándose por parte de los contenedores del usuario.

Crear credenciales de servicio: un adversario malintencionado puede aprovechar el acceso que ya tiene en el entorno y crear nuevas credenciales para su uso en caso de que se pierda el método de acceso inicial. Esto puede hacerse mediante la creación de un token de acceso a la SCM, a la propia aplicación, a los recursos en la nube, etc.

Escalación de privilegios

Los atacantes usan las técnicas de escalación de privilegios para elevar los privilegios en el entorno de la víctima y obtener privilegios más elevados para los recursos que ya han sido vulnerados:

Secretos en repositorios privados: aprovechando un método de acceso inicial ya obtenido, un atacante podría examinar repositorios privados para obtener secretos ocultos. Las posibilidades de encontrar secretos ocultos en un repositorio privado son mayores que en un repositorio público, ya que, desde el punto de vista del desarrollador, esto es inaccesible desde fuera de la organización.

Confirmación e inserción de cambios en ramas protegidas: la canalización tiene acceso al repositorio, que se puede configurar con un acceso flexible, lo que podría permitir insertar código directamente en ramas protegidas. Esto permite a un adversario insertar código directamente en las ramas importantes sin intervención del equipo.

Certificados e identidades de servicios de metadatos: una vez que un ataque se ejecuta en canalizaciones hospedadas en la nube, el atacante podría acceder a los servicios de metadatos desde dentro de la canalización y extraer certificados (requiere privilegios elevados) e identidades de estos servicios.

Acceso de credencial

Un atacante usa técnicas de acceso con credenciales para robar credenciales:

Credenciales de usuario: en los casos en los que el cliente requiere acceso a servicios externos desde la canalización de CI (por ejemplo, una base de datos externa), estas credenciales residen dentro de la canalización (pueden establecerse mediante secretos de CI, variables de entorno, etc.) y podrían ser accesibles para el adversario.

Credenciales de servicio: hay casos en los que el atacante puede encontrar credenciales de servicio, como nombres de entidad de seguridad de servicio (SPN), tokens de firma de acceso compartido (SAS) y mucho más, lo que podría permitir el acceso a otros servicios directamente desde la canalización.

Desplazamiento lateral

La táctica de desplazamiento lateral hace referencia a las técnicas que usan los atacantes para desplazarse a través de diferentes recursos. En entornos de CI/CD, esto puede hacer referencia a la migración a los recursos de implementación, a compilar artefactos y registros, o a nuevos destinos.

Vulneración de artefactos de compilación: como en otros ataques de la cadena de suministro, una vez que el atacante tiene control de las canalizaciones de CI, puede interferir con los artefactos de compilación. De este modo, se podría insertar código malintencionado en los materiales de compilación antes de realizar la compilación, por lo que se insertaría la funcionalidad malintencionada en los artefactos de compilación.

Inserción del registro: si la canalización está configurada con un registro para los artefactos de compilación, el atacante podría infectar el registro con imágenes malintencionadas, que posteriormente los contenedores descargarían y ejecutarían mediante este registro.

Propagación a recursos de implementación: si la canalización está configurada con acceso a los recursos de implementación, el atacante tiene el mismo acceso a estos recursos, lo que permite que el ataque se propague. Esto podría dar lugar a la ejecución de código, la filtración de datos y mucho más, en función de los permisos concedidos a las canalizaciones.

Evasión defensiva

Los atacantes podrían usar técnicas de evasión de defensa para omitir las defensas usadas en un entorno de DevOps y permitir que los ataques continúen desapercibidos:

Manipulación de registros de servicio: los registros de servicio permiten a los defensores detectar ataques en su entorno. Un ataque que se ejecuta dentro de un entorno (por ejemplo, en las canalizaciones de compilación) podría cambiar los registros para impedir que los defensores observen el ataque. Esto es similar a un atacante que cambia los registros de historial en una máquina Linux, lo que impide que cualquier observador vea los comandos ejecutados por el atacante.

Manipulación de compilación: si un atacante no desea dejar ningún seguimiento en el servicio SCM, este puede cambiar el proceso de compilación para insertar el código malintencionado. Esto puede hacerse de varias maneras:

• Cambiar el código sobre la marcha: cambiar el código justo antes de que comience el proceso de compilación, sin cambiarlo en el repositorio ni dejar ningún seguimiento en él.
  
• Compilador alterado: cambiar el compilador en el entorno de compilación para introducir el código malintencionado sin dejar ningún seguimiento antes de que comience ese proceso.

Volver a configurar las protecciones de ramas: las herramientas de protección de ramas permiten a una organización configurar los pasos antes de que se apruebe una solicitud de incorporación de cambios o confirmación en una rama. Una vez que un atacante tiene permisos de administrador, puede cambiar estas configuraciones e introducir código en la rama sin intervención del usuario.

Impacto

La táctica de impacto hace referencia a las técnicas que un atacante podría usar para aprovechar el acceso a los recursos de CI/CD con fines malintencionados y no como otro paso en el ataque, ya que estas técnicas podrían ser ruidosas y fáciles de detectar:

Ataque de denegación de servicio distribuido (DDoS): un adversario podría usar los recursos de proceso a los que obtuvo acceso para ejecutar ataques distribuidos por denegación de servicios (DDoS) en destinos externos.

Minería de criptomonedas: los recursos de proceso se pueden usar para la criptominería controlada por un adversario.

Denegación de servicio local (DoS): una vez que el ataque se ejecuta en las canalizaciones de CI, el atacante puede realizar un ataque de denegación de servicio desde dichas canalizaciones a los clientes apagando agentes, reiniciándolos o sobrecargando las máquinas virtuales.

Eliminación de recursos: un atacante con acceso a recursos (recursos en la nube, repositorios, etc.) podría eliminar permanentemente los recursos para lograr la denegación de servicios.

Exfiltración

La táctica de filtración hace referencia a diferentes técnicas que un atacante podría usar para filtrar datos confidenciales del entorno víctima:

Clonación de repositorios privados: una vez que los atacantes tienen acceso a las canalizaciones de CI, también obtienen acceso a los repositorios privados (por ejemplo, el GITHUB_TOKEN se puede usar en GitHub) y, por tanto, podrían clonar y acceder al código, obteniendo así acceso a la dirección IP privada.

Registros de canalización: un adversario podría acceder a los registros de ejecución de canalización, ver el historial de acceso, los pasos de compilación, etc. Estos registros pueden contener información confidencial sobre la compilación, la implementación y, en algunos casos, incluso sobre las credenciales de los servicios para las cuentas de usuario y mucho más.

Filtración de datos desde recursos de producción: en los casos en los que las canalizaciones pueden acceder a los recursos de producción, los atacantes también tendrán acceso a estos recursos. Por tanto, pueden abusar de este acceso para la filtración de datos de producción.

Recomendaciones de administración de posturas de DevOps

Cuando los escáneres de DevOps descubren desviaciones de los procedimientos recomendados de seguridad en sistemas de administración de código fuente y canalizaciones o entrega continuas, Defender for Cloud genera recomendaciones precisas y accionables. Estas recomendaciones tienen las siguientes ventajas:

• Visibilidad mejorada: obtenga información completa sobre la posición de seguridad de los entornos de DevOps, lo que garantiza una comprensión equilibrada de las vulnerabilidades existentes. Identifique las reglas de protección de rama que faltan, los riesgos de escalación de privilegios y las conexiones no seguras para evitar ataques.
  
• Acción basada en prioridad: filtre los resultados por gravedad para abordar primero las vulnerabilidades más críticas e invertir recursos y esfuerzos de forma más eficaz.
• Reducción de la superficie expuesta a ataques: aborde las brechas de seguridad resaltadas para minimizar significativamente las superficies expuestas a ataques vulnerables, lo que protege las defensas contra posibles amenazas.
• Notificaciones en tiempo real: permite la integración con automatizaciones de flujo de trabajo para recibir alertas inmediatas cuando se modifican las configuraciones seguras, lo que permite una acción rápida y garantiza un cumplimiento continuo de los protocolos de seguridad.