Compartir a través de

Seguridad de DevOps

La seguridad de DevOps integra prácticas de seguridad a lo largo del ciclo de vida de desarrollo de software (SDLC), desde el diseño inicial y la codificación a través de la compilación, prueba e implementación en producción. A diferencia de los enfoques de seguridad tradicionales que tratan la seguridad como una puerta final, la seguridad de DevOps inserta controles de seguridad, pruebas automatizadas y supervisión continua en cada fase de la canalización de desarrollo. Este enfoque reconoce que la entrega de software moderna se basa en canalizaciones complejas de CI/CD, dependencias de terceros, infraestructura como código y implementaciones automatizadas, cada una de las cuales presenta vectores de ataque potenciales que los adversarios aprovechan activamente. Al aplicar los principios de confianza cero (supongamos que se infringen, comprueban explícitamente) y las estrategias de defensa en profundidad, la seguridad de DevOps garantiza que el código, las dependencias, las configuraciones de infraestructura y los procesos de canalización sigan siendo confiables y resistentes a alteraciones desde el diseño a través de la producción. Sin una seguridad completa de DevOps, las organizaciones se enfrentan a riesgos críticos, incluidos los ataques de la cadena de suministro, la exposición de credenciales en canalizaciones, la inyección de código malintencionado, las imágenes de contenedor vulnerables y los cambios de infraestructura no autorizados que pueden establecer puertas traseras persistentes que afectan a todos los consumidores de bajada.

Estos son los tres pilares básicos del dominio de seguridad de DevOps Security.

Proteja el diseño y la cadena de suministro: Realice el modelado de amenazas estructurados al principio. Proteja la cadena de suministro con análisis de dependencias y licencias, administración de vulnerabilidades y generación SBOM. Compruebe la procedencia y la integridad de todos los componentes.

Controles relacionados:

Cambie a la izquierda los controles de seguridad: Cambie los controles de seguridad a la izquierda mediante la integración de SAST, el examen de secretos, el examen de IaC y DAST en la canalización de CI/CD. Centralice la administración de secretos (por ejemplo, Key Vault), restrinja la autoridad de cambio de canalización y examine y proteja continuamente los artefactos (como las imágenes de contenedor y máquina virtual) antes de la implementación.

Controles relacionados:

Supervisión y auditoría de actividades de DevOps: Recopile y reenvíe los registros de auditoría y seguridad de DevOps a una plataforma de análisis central para la correlación y la respuesta. Detecte cambios no autorizados en la canalización, escalaciones de privilegios, confirmaciones anómalas y ejecuciones fuera de horas.

Controles relacionados:

DS-1: Realizar el modelado de amenazas

Principio de seguridad

Implemente el modelado sistemático de amenazas mediante la metodología STRIDE durante la fase de diseño para identificar posibles amenazas de seguridad, priorizar los riesgos e implementar las mitigaciones adecuadas antes de que comience el desarrollo de código. Este enfoque hacia la izquierda reduce los costos de corrección y mejora la postura general de seguridad.

Riesgo para mitigar

Las organizaciones que no realizan el modelado de amenazas durante la fase de diseño funcionan con puntos ciegos críticos que los adversarios aprovechan sistemáticamente. Sin análisis sistemático de amenazas:

  • Defectos de arquitectura tardía: Las vulnerabilidades de diseño insertadas requieren una refactorización costosa en producción, con costos de corrección considerablemente mayores que solucionar problemas durante la fase de diseño.
  • Superficies de ataque no identificadas: Los vectores de amenazas, como los límites de confianza no seguros, los requisitos de autenticación que faltan o las protecciones de flujo de datos inadecuadas siguen sin documentarse, lo que permite a los atacantes aprovechar las debilidades conocidas que los defensores no reconocen.
  • Controles de seguridad insuficientes: Los controles de seguridad insuficientes o que faltan (cifrado, autenticación, autorización, registro de auditoría) resultan del análisis de amenazas incompleto, lo que crea brechas aprovechables en la estrategia de defensa en profundidad.
  • Puntos ciegos de cumplimiento: Los requisitos normativos (PCI-DSS, HIPAA, SOX) que exigen la validación de diseño seguro no se pueden cumplir sin los modelos de amenazas documentados y la evidencia de mitigación.
  • Acumulación de deudas de seguridad: Las adiciones continuas de características sin modelado de amenazas crean deuda técnica de seguridad compuesta, lo que hace que los sistemas sean progresivamente más vulnerables y difíciles de proteger retroactivamente.

La falta de modelado de amenazas aumenta la probabilidad de vulneración, amplía el tiempo de permanencia y impulsa un costo de corrección mucho mayor frente a la mitigación temprana de la fase de diseño.

MITRE ATT&CK

  • Acceso inicial (TA0001): aprovecha la aplicación orientada al público (T1190) aprovechando los errores arquitectónicos en la autenticación, la administración de sesiones o la validación de entrada que el modelado de amenazas identificaría.
  • Elevación de privilegios (TA0004): abuso del mecanismo de control de elevación (T1548) que aprovecha la separación de privilegios insuficiente o comprobaciones de autorización que faltan dentro de la arquitectura del sistema.
  • Evasión de defensa (TA0005): deteriorar las defensas (T1562) explotando la ausencia de registros de auditoría, las lagunas en la supervisión o la telemetría de seguridad insuficiente diseñada en el sistema.

DS-1.1: Implementación del modelado de amenazas basado en STRIDE

El modelado sistemático de amenazas durante la fase de diseño proporciona la base para la arquitectura de software segura mediante la identificación de vulnerabilidades antes de que comience el desarrollo. La solución de problemas de seguridad en la fase de diseño reduce drásticamente los costos de corrección y evita que los errores arquitectónicos se inserte en los sistemas de producción. La identificación temprana de amenazas garantiza que los controles de seguridad se integran en la arquitectura en lugar de adaptarse más adelante.

Implemente el siguiente enfoque estructurado para establecer el modelado de amenazas:

  • Establecer metodología de STRIDE sistemática: Establezca el modelado sistemático de amenazas como una actividad de fase de diseño obligatoria mediante la metodología STRIDE (suplantación de identidad, manipulación, rechazo, divulgación de información, denegación de servicio, elevación de privilegios). Empiece por crear diagramas de flujo de datos (DFD) que asignen componentes del sistema, flujos de datos, límites de confianza y dependencias externas. Para cada componente y flujo de datos, evalúe sistemáticamente las posibles amenazas en las seis categorías STRIDE, priorice los riesgos en función de la probabilidad y el impacto, y documente mitigaciones específicas antes de que comience el desarrollo.

  • Usar herramientas de modelado de amenazas estructuradas: Use herramientas de modelado de amenazas estructuradas como Microsoft Threat Modeling Tool para mantener la coherencia y aprovechar las plantillas pregeneradas para patrones de arquitectura comunes (aplicaciones web, API, microservicios, soluciones de IoT). La herramienta facilita la creación de DFD, la identificación automatizada de amenazas basada en tipos de componentes y flujos de datos, y genera recomendaciones de mitigación accionables con controles de seguridad asociados. Almacene los modelos de amenazas como documentos versionados en el control de código fuente junto con la documentación de la arquitectura.

  • Integración en flujos de trabajo de desarrollo: Integre las salidas de modelado de amenazas directamente en flujos de trabajo de desarrollo mediante la exportación de amenazas identificadas a elementos de trabajo de Azure DevOps con criterios claros de propiedad, prioridad y aceptación. Implemente puertas de revisión de arquitectura que requieran modelos de amenazas completados antes de la aprobación del diseño y establezca comprobaciones de solicitudes de incorporación de cambios que desencadenan revisiones de modelos de amenazas cuando se detectan cambios en la arquitectura. Esto garantiza que el análisis de amenazas permanezca sincronizado con la evolución del sistema durante todo el ciclo de vida de desarrollo.

DS-1.2: Automatización de la integración del análisis de amenazas

El escalado del modelado de amenazas en organizaciones grandes requiere automatización y capacidad distribuida para evitar que las revisiones de seguridad se conviertan en cuellos de botella de desarrollo. Los flujos de trabajo automatizados de identificación de amenazas insertados en los procesos de iniciación y solicitud de incorporación de cambios del proyecto garantizan un análisis de seguridad coherente sin intervención manual para cada proyecto. La creación de conocimientos de seguridad en los equipos de desarrollo mediante programas de habilitación crea prácticas de modelado de amenazas sostenibles y escalables.

Implemente estas funcionalidades de automatización y habilitación:

  • Escalado a través de la automatización y habilitación: Escale el modelado de amenazas en toda la organización mediante la automatización y la habilitación. Inserte cuestionarios de seguridad en plantillas de inicio de proyecto que evalúen automáticamente el nivel de riesgo, determinen los requisitos de modelado de amenazas y asignen los puntos de comprobación de seguridad adecuados en función de la clasificación de datos, la exposición externa y el ámbito normativo. Automatice los activadores de revisión de arquitectura en los flujos de trabajo de pull request que detecten cambios en los límites del sistema, los flujos de autenticación o la manipulación de la lógica de datos, dirigiendo dichos cambios a los arquitectos de seguridad para la validación del modelo de amenazas.

  • Creación de funcionalidad distribuida con campeones de seguridad: Establezca un programa de campeones de seguridad para crear la funcionalidad de modelado de amenazas distribuida dentro de los equipos de desarrollo. Entrene a los campeones en la metodología STRIDE, proporciónelas con plantillas y herramientas de modelado de amenazas, y les permita facilitar las sesiones de modelado de amenazas para sus equipos. Los campeones de seguridad sirven como primera línea de revisión, escalando escenarios complejos a equipos de seguridad centralizados al tiempo que permiten que la mayoría del modelado de amenazas se produzca sin cuellos de botella.

Implementación automatizada del análisis de amenazas:

  • Evaluación basada en cuestionarios: Cuestionarios de seguridad estandarizados integrados en plantillas de Azure DevOps para la identificación coherente de amenazas
  • Programa de campeones de seguridad: Campeones de seguridad designados en cada equipo de desarrollo entrenados en la facilitación del modelado de amenazas
  • Automatización de revisión de arquitectura: Comprobaciones automatizadas en solicitudes de incorporación de cambios para las actualizaciones del diagrama de arquitectura que requieren revisiones de modelos de amenazas
  • Modelo de amenazas como código: Definiciones de modelo de amenazas controladas por versiones mediante formatos estructurados (JSON/YAML) que permiten el análisis automatizado

Ejemplo de implementación

Una organización de servicios financieros sufrió una vulneración de datos cuando los atacantes aprovecharon el error de autorización en la API de pago que nunca se identificó durante el desarrollo, lo que da lugar a transacciones fraudulentas significativas y multas normativas.

Desafiar: Arquitectura de microservicios con numerosas API implementadas sin revisión de seguridad. Los equipos de desarrollo no tienen experiencia en seguridad para identificar amenazas. Problemas de seguridad de la arquitectura detectados solo después de incidentes de producción.

Enfoque de solución:

  • Modelado de amenazas STRIDE: Se implementó microsoft Threat Modeling Tool para todos los microservicios y puntos de conexión de API con diagramas de flujo de datos que muestran flujos de datos confidenciales y de arquitectura.
  • Programa de campeones de la seguridad: Facilitadores de modelado de amenazas formados en cada equipo de desarrollo que facilitan la seguridad integrada en el diseño, evitando así cuellos de botella en el equipo de seguridad central.
  • Integración automatizada del flujo de trabajo: Revisiones integradas del modelo de amenazas en flujos de trabajo de pull request de Azure DevOps que requieren aprobación de seguridad para los cambios de arquitectura.

Resultado: Se han identificado numerosos problemas de seguridad previos a la implementación que impiden posibles infracciones. Vulnerabilidades de seguridad considerablemente reducidas en producción. Las revisiones de seguridad agregaron un tiempo mínimo al ciclo de desarrollo.

Nivel de importancia crítica

Imprescindible.

Asignación de controles

  • NIST SP 800-53 Rev.5: SA-11, SA-15, PL-8, RA-3, RA-5
  • PCI-DSS v4: 6.3.1, 6.3.2, 12.3.1
  • Cis Controls v8.1: 14.2, 14.3
  • NIST CSF v2.0: ID.RA-3, PR. IP-2
  • ISO 27001:2022: A.5.12, A.8.25
  • SOC 2: CC3.2, CC7.1

DS-2: Protección de la cadena de suministro de software

Principio de seguridad

Implemente confianza cero para las dependencias comprobando la procedencia, integridad y posición de seguridad de todos los componentes de terceros antes de la integración. Examine continuamente las dependencias en busca de vulnerabilidades, mantenga un listado completo de materiales de software (SBOM) y aplique actualizaciones de seguridad automatizadas para minimizar la superficie de ataque de la cadena de suministro.

Riesgo para mitigar

Los ataques de la cadena de suministro de software representan amenazas críticas porque los adversarios aprovechan las relaciones de confianza entre organizaciones y componentes de terceros para lograr un impacto generalizado con un esfuerzo mínimo. Sin seguridad completa de la cadena de suministro:

  • Dependencias malintencionadas: Los adversarios insertan puertas traseras en bibliotecas populares de código abierto (ataques al estilo de SolarWinds) o crean paquetes con errores tipográficos que ejecutan código malicioso durante la instalación o el tiempo de ejecución.
  • Bibliotecas de terceros vulnerables: Los CVE conocidos en dependencias (Log4Shell, Heartbleed, vulnerabilidades de Struts) permanecen sin parches durante semanas o meses debido a la falta de visibilidad y la gestión automatizada de vulnerabilidades.
  • Artefactos de compilación en peligro: Los atacantes manipulan archivos binarios compilados, imágenes de contenedor o paquetes de implementación durante el almacenamiento o tránsito, insertando malware que omite la revisión del código fuente.
  • Ataques de confusión de dependencias: Los actores malintencionados cargan paquetes en repositorios públicos con nombres que coinciden con paquetes privados internos, aprovechando la lógica de resolución del administrador de paquetes para sustituir código malintencionado.
  • Riesgos de dependencia transitiva: Las vulnerabilidades en dependencias indirectas (dependencias de dependencias) permanecen invisibles sin el análisis profundo del árbol de dependencias y la generación SBOM.
  • Falta de comprobación de la procedencia: La ausencia de comprobación criptográfica permite ataques de sustitución de paquetes en los que los paquetes legítimos se reemplazan por versiones malintencionadas.

El compromiso de la cadena de suministro permite un gran impacto, puertas traseras persistentes en bibliotecas de confianza y una alta capacidad de evasión debido a la apariencia legítima.

MITRE ATT&CK

  • Acceso inicial (TA0001): compromiso de la cadena de suministro (T1195.001) mediante el uso de dependencias de software y herramientas de desarrollo comprometidas para obtener un punto de apoyo inicial en los entornos de destino, y relaciones de confianza (T1199) aprovechando la confianza entre organizaciones y proveedores de software de terceros para entregar actualizaciones malintencionadas.
  • Ejecución (TA0002): intérprete de scripting y comandos (T1059) que ejecuta código malintencionado incrustado en scripts de instalación de dependencias o ganchos posteriores a la instalación.
  • Persistencia (TA0003): poner en peligro los archivos binarios de software cliente (T1554) incrustando puertas traseras en bibliotecas compiladas que persisten en las actualizaciones de la aplicación.

DS-2.1: Implementar el examen de dependencias y la administración

La administración completa de la seguridad de dependencias evita ataques de cadena de suministro al mantener la visibilidad de todos los componentes de terceros, supervisar continuamente las vulnerabilidades y automatizar los procesos de corrección. Las aplicaciones modernas se basan en cientos o miles de dependencias (directas y transitivas), lo que hace que la evaluación manual de la seguridad sea imposible y crear una amplia superficie de ataque a través de bibliotecas vulnerables. El análisis automatizado de dependencias con supervisión continua garantiza que las organizaciones detecten y corrijan vulnerabilidades antes de la explotación.

Establezca la seguridad de dependencia continua a través de estas funcionalidades principales:

  • Establecer visibilidad completa y generación SBOM: Establezca la administración continua de la seguridad de dependencias con tres funcionalidades principales: visibilidad completa, detección automatizada de vulnerabilidades y corrección proactiva. Empiece por generar inventarios de dependencias completos que asignen dependencias directas (declaradas explícitamente en manifiestos de paquete) y dependencias transitivas (dependencias de dependencias) en todos los repositorios. Mantener la lista de materiales de software (SBOM) en formatos estándar del sector (SPDX, CiclónDX) para la preparación de cumplimiento normativo y respuesta a incidentes.

  • Implemente el examen y la corrección automatizadas de vulnerabilidades: Implemente el examen automatizado de vulnerabilidades que supervisa continuamente las dependencias de la base de datos de vulnerabilidades nacionales (NVD), la base de datos de asesoramiento de GitHub y los avisos de seguridad específicos del lenguaje. Configura alertas en tiempo real cuando se divulguen nuevos CVE que afecten a la pila de dependencias, y enrutar según la gravedad a los equipos correspondientes. Habilite las funcionalidades de actualización de seguridad automatizadas que generan solicitudes de incorporación de cambios con actualizaciones de versión de dependencia, incluidas las pruebas de compatibilidad y la resolución inteligente de conflictos de combinación para reducir la carga de corrección manual.

  • Integrar la validación de seguridad en los flujos de trabajo de desarrollo: Integre la validación de seguridad de las dependencias directamente en los flujos de trabajo de desarrollo mediante revisiones automáticas de solicitudes de incorporación de cambios, que evalúen el impacto en la seguridad al señalar nuevas dependencias con vulnerabilidades conocidas, problemas de cumplimiento de licencias o características sospechosas (suplantación por errores tipográficos, falta de reputación del mantenedor). Establezca puertas de aprobación para cambios de dependencia de alto riesgo y aplique políticas que prohíban fusionar dependencias con vulnerabilidades críticas en ramas protegidas.

  • Ampliar la visibilidad a los entornos de producción: Amplíe la visibilidad más allá del código fuente a los entornos implementados mediante herramientas como Microsoft Defender for Cloud DevOps Security para correlacionar las dependencias de código con cargas de trabajo en ejecución, identificar rutas de acceso de ataque a través de cadenas de dependencias y priorizar la corrección en función de la exposición de producción real en lugar de un riesgo teórico por sí solo. Las herramientas como GitHub Advanced Security proporcionan una visualización completa del grafo de dependencias, actualizaciones automatizadas controladas por Dependabot y compatibilidad con patrones de vulnerabilidad personalizados para ecosistemas de paquetes propietarios.

Ejemplo de implementación

Una organización sanitaria detectó un paquete npm malintencionado en la aplicación de producción que exfiltraba los datos de los pacientes durante meses. La investigación reveló amplias dependencias vulnerables con CVEs conocidos, incluyendo la vulnerabilidad crítica de Log4Shell.

Desafío: Miles de dependencias en cientos de repositorios sin visibilidad sobre vulnerabilidades ni paquetes malintencionados. Las revisiones manuales de dependencias consumieron semanas para cada aplicación. La auditoría normativa identificó brechas críticas en la cadena de suministro.

Enfoque de solución:

  • Administración automatizada de vulnerabilidades: Se ha habilitado GitHub Advanced Security con Dependabot escaneando dependencias y creando automáticamente pull requests para las actualizaciones de seguridad.
  • Transparencia de la cadena de suministro: Se implementó la herramienta SBOM de Microsoft que genera la lista de materiales de software en formato SPDX para el cumplimiento normativo y la respuesta a incidentes.
  • Comprobación del paquete: Se ha configurado Azure Artifacts con comprobación de firmas y anclaje de dependencias que impiden ataques de confusión y sustitución de paquetes no autorizadas.
  • Supervisión de la seguridad de DevOps:Microsoft Defender for Cloud DevOps Security desplegado para la rastreabilidad de código a nube.

Resultado: Se detectaron y corregiron rápidamente las amplias dependencias vulnerables. Se evitaron varios incidentes de paquetes malintencionados a través de la comprobación automatizada. Se ha logrado el cumplimiento normativo con la documentación completa de SBOM.

Nivel de importancia crítica

Imprescindible.

Asignación de controles

  • NIST SP 800-53 Rev.5: SR-3, SR-4, SR-6, SA-12, SA-15(9), RA-5
  • PCI-DSS v4: 6.2.4, 6.3.2, 6.3.3
  • Cis Controls v8.1: 16.1, 16.2, 16.11
  • NIST CSF v2.0: ID.SC-2, ID.SC-4, DE.CM-8
  • ISO 27001:2022: A.5.19, A.5.22, A.5.23
  • SOC 2: CC3.2, CC8.1

DS-3: Protección de la infraestructura de DevOps

Principio de seguridad

Implemente la defensa en profundidad para la infraestructura de compilación a través de una administración completa de secretos, controles de acceso a canalizaciones con puertas de aprobación, configuración segura del agente de compilación y supervisión continua. Elimine las credenciales codificadas e implemente el acceso de privilegios mínimos para proteger la integridad del proceso de desarrollo e implementación de software.

Riesgo para mitigar

La infraestructura de DevOps no segura crea vulnerabilidades críticas que los adversarios aprovechan para poner en peligro toda la cadena de entrega de software. Sin seguridad de infraestructura completa:

  • Pipelines de CI/CD comprometidas: Los atacantes obtienen acceso a los pipelines de compilación a través de credenciales robadas, vulnerabilidades explotadas o acceso interno, lo que permite la inserción de código, la manipulación de artefactos o la manipulación de despliegue que afecta a todos los consumidores finales.
  • Secretos expuestos en los registros de compilación y artefactos: Las credenciales codificadas de forma dura, las claves de API, los certificados y las cadenas de conexión se filtran a través de registros de canalización, mensajes de error o artefactos compilados, lo que proporciona a los atacantes acceso directo a entornos de producción.
  • Modificaciones de canalización no autorizadas: La falta de flujos de trabajo de control de cambios y aprobación permite a los actores malintencionados modificar definiciones de canalización, insertar pasos de compilación malintencionados o modificar configuraciones de implementación sin detección.
  • Controles de acceso insuficientes: Las asignaciones de roles excesivamente permisivas y la falta de separación de tareas permiten el movimiento lateral, la elevación de privilegios y el establecimiento de acceso persistente dentro de la infraestructura de DevOps.
  • Agentes de compilación no seguros: Los agentes de compilación no revisados, mal configurados o comprometidos proporcionan a los atacantes acceso persistente al entorno de compilación y posibles puntos dinámicos en redes de producción.
  • Faltan seguimientos de auditoría: El registro y la supervisión inadecuados de las actividades de DevOps impiden la detección de acceso no autorizado, modificaciones sospechosas o amenazas internas.

La vulneración de la infraestructura permite a los atacantes inyectar código en el origen, omitir las canalizaciones de confianza y afectar a todas las aplicaciones descendentes.

MITRE ATT&CK

  • Acceso inicial (TA0001): cuentas válidas (T1078) usando credenciales robadas o secretos de principal de servicio para acceder a plataformas y canalizaciones de DevOps.
  • Persistencia (TA0003): manipulación de cuentas (T1098) creando principales de servicio de puerta trasera, tokens de acceso personal o claves SSH para mantener el acceso.
  • Acceso a credenciales (TA0006): credenciales no seguros (T1552.001) que recopilan secretos de registros de canalización, variables de entorno o archivos de configuración.
  • Evasión de defensa (TA0005): afecta a las defensas (T1562) deshabilitando los pasos de examen de seguridad, el registro de auditoría o las puertas de aprobación en las definiciones de canalización.

DS-3.1: Implementación de la administración de secretos para canalizaciones

La administración centralizada de secretos elimina la exposición de credenciales en canalizaciones de DevOps mediante la eliminación de secretos codificados de forma rígida del código, los archivos de configuración y las definiciones de canalización. Las credenciales insertadas en variables de entorno, YAML de canalización o repositorios de origen representan el vector de ataque principal para el compromiso de la canalización, permitiendo a los atacantes que obtienen acceso a repositorios o registros extraer credenciales de producción. La implementación del almacenamiento secreto protegido criptográficamente con patrones de acceso Just-In-Time y recuperación dinámica impide el robo de credenciales al tiempo que mantiene la eficacia operativa.

Configure la administración de secretos con estos controles de seguridad:

  • Elimine las credenciales incluidas de forma fija en el código con almacenamiento centralizado: Elimine las credenciales incluidas de forma fija en las definiciones de canalización y el código fuente centralizando todos los secretos en una infraestructura dedicada para la gestión de secretos, con controles de acceso criptográfico y seguimientos de auditoría completos. Establezca el principio de que los secretos nunca se deben almacenar en archivos YAML de canalización, variables de entorno visibles en registros o archivos de configuración en repositorios, estos son los vectores principales para la exposición de credenciales en entornos de DevOps.

  • Configuración de la recuperación dinámica de secretos con identidades administradas: Implemente el almacenamiento de secretos centralizado mediante soluciones como Azure Key Vault que proporcionan almacenamiento secreto cifrado, directivas de acceso pormenorizadas, rotación automática de secretos y registro de auditoría completo. Configure canalizaciones para recuperar secretos dinámicamente en tiempo de ejecución a través de conexiones de servicio seguras en lugar de insertarlos en definiciones de canalización. Utilice identidades administradas o federación de identidades de carga de trabajo para autenticar el acceso de tubería a almacenes secretos, lo que elimina la necesidad de credenciales de principal de servicio de larga duración que se convierten en objetivos de robo.

  • Aplique el acceso Just-In-Time con puertas de aprobación: Aplique patrones de acceso de secretos Just-In-Time en los cuales los secretos solo se recuperan cuando sea necesario, con revocación automática después de la finalización de la canalización para minimizar la exposición de la duración de las credenciales. Implemente restricciones de acceso con límite de tiempo y requiera autorización de varias personas (fases de aprobación) para el acceso a secretos de producción en la canalización, lo que garantiza que ninguna cuenta comprometida pueda acceder a credenciales confidenciales sin verificación adicional.

  • Establecer controles de acceso a la infraestructura en capas: Establezca controles de acceso en capas para la infraestructura de DevOps: restrinja los derechos de modificación de canalización al personal revisado por la seguridad, aplique permisos específicos del entorno que requieran aprobación para implementaciones de producción, implemente restricciones de conexión de servicio de nivel de repositorio que impidan que las canalizaciones accedan a secretos fuera de su ámbito previsto e implementen agentes de compilación autohospedados protegidos con aislamiento de red para cargas de trabajo confidenciales. Integre el análisis de seguridad de infraestructura como código en canalizaciones para evitar la implementación de recursos mal configurados que podrían exponer secretos o crear rutas de acceso no autorizadas.

Ejemplo de implementación

Una organización minorista sufrió una violación de seguridad cuando los atacantes usaron credenciales de entidad de servicio robadas, encontradas en los registros de canalización, para acceder a las bases de datos de producción y exponer millones de registros de clientes.

Desafío: Cadenas de conexión de base de datos y claves de API codificadas de forma fija en variables de canalización. Los permisos excesivamente permisivos del pipeline permitían que cualquier desarrollador desplegara en producción. La vulneración del agente de compilación proporcionó acceso persistente a la infraestructura.

Enfoque de solución:

  • Administración centralizada de secretos: Se implementó la integración de Azure Key Vault, eliminando los secretos incrustados en las canalizaciones. La autenticación de identidad administrada configurada elimina el riesgo de exposición de credenciales.
  • Controles de acceso de canalización: Se establecieron puertas de aprobación y permisos específicos del entorno mediante entornos de Azure DevOps que requieren aprobación del equipo de seguridad para las implementaciones de producción.
  • Agentes de compilación protegidos: Se han implementado agentes autohospedados con protección de seguridad y aislamiento de red para cargas de trabajo confidenciales que procesan datos regulados.
  • Examen de seguridad de la infraestructura: Validación de seguridad integrada para plantillas de ARM y configuraciones de Terraform que impiden la implementación incorrecta de la configuración.

Resultado: Se eliminaron los secretos de los registros de canalización que impiden el robo de credenciales. Elimina implementaciones de producción no autorizadas. Se detectaron y bloquearon las configuraciones incorrectas de infraestructura antes de la implementación.

Nivel de importancia crítica

Imprescindible.

Asignación de controles

  • NIST SP 800-53 Rev.5: AC-2, AC-3, AC-6, SC-12, SC-13, AU-2, AU-6
  • PCI-DSS v4: 8.3.2, 8.6.1, 8.6.3, 12.3.3
  • Cis Controls v8.1: 4.1, 4.7, 6.1, 6.5
  • NIST CSF v2.0: PR. AC-4, PR. DS-5, DE. CM-7
  • ISO 27001:2022: A.5.15, A.5.16, A.8.3
  • SOC 2: CC6.1, CC6.6, CC6.7

DS-4: Integrar pruebas estáticas de seguridad de aplicaciones (SAST)

Principio de seguridad

Implemente pruebas completas de seguridad automatizadas a través de varios escáneres especializados de pruebas de seguridad de aplicaciones estáticas (SAST) integrados en cada proceso de compilación. Utilice la cobertura de múltiples escáneres para una detección integral, implemente el escaneo de secretos con protección al insertar y despliegue análisis de código semántico para identificar y bloquear vulnerabilidades antes de que lleguen a producción.

Riesgo para mitigar

Las vulnerabilidades de nivel de código que escapan la detección durante el desarrollo crean debilidades de seguridad persistentes que los adversarios aprovechan sistemáticamente. Sin una integración completa de SAST:

  • Vulnerabilidades de inyección: La inyección de código SQL, el scripting entre sitios (XSS), la inserción de comandos y los errores de inyección de LDAP permiten a los atacantes manipular la lógica de la aplicación, extraer datos confidenciales o ejecutar código arbitrario.
  • Credenciales codificadas de forma dura: Los desarrolladores confirman accidentalmente contraseñas, claves de API, certificados y cadenas de conexión en repositorios de código fuente, lo que proporciona a los atacantes acceso directo a los sistemas y datos de producción.
  • Implementaciones criptográficas no seguras: Algoritmos de cifrado débiles (DES, MD5), claves de cifrado codificadas de forma segura, vectores de inicialización incorrectos o longitudes de clave insuficientes ponen en peligro la confidencialidad e integridad de los datos.
  • Desbordamientos del búfer y daños en la memoria: Las operaciones de memoria no seguras en aplicaciones de C/C++ permiten la ejecución arbitraria de código, la elevación de privilegios y los ataques por denegación de servicio.
  • Errores de lógica empresarial: Las omisións de autenticación, las brechas de autorización, las condiciones de carrera y la validación de entrada insuficiente permiten la elevación de privilegios, el fraude y el acceso no autorizado.
  • Configuraciones incorrectas de infraestructura como código (IaC): Los manifiestos inseguros de Terraform, plantillas de ARM o Kubernetes implementan infraestructura vulnerable con acceso excesivamente permisivo, cifrado que falta o puntos de conexión de administración expuestos.

Sin SAST automatizado, las vulnerabilidades se acumulan como deuda técnica, amplían el tiempo de permanencia y se vuelven costosas de corregir en producción.

MITRE ATT&CK

  • Acceso inicial (TA0001): aprovecha la aplicación orientada al público (T1190) aprovechando las vulnerabilidades de inyección o las omisións de autenticación en el código de aplicación.
  • Ejecución (TA0002): explotación para la ejecución en el cliente (T1203) que aprovecha vulnerabilidades del lado del cliente como XSS o deserialización no segura.
  • Acceso a credenciales (TA0006): credenciales de almacenes de contraseñas (T1555) que extraen credenciales codificadas de forma rígida del código fuente, los archivos de configuración o los archivos binarios compilados.
  • Elevación de privilegios (TA0004): explotación para la elevación de privilegios (T1068) mediante desbordamientos del búfer o corrupción de memoria para el acceso elevado.

DS-4.1: Implementación de la canalización SAST de varios escáneres

Las pruebas completas de seguridad de aplicaciones estáticas integradas en cada compilación proporcionan detección temprana de vulnerabilidades de nivel de código antes de llegar a entornos de producción. Las aplicaciones modernas usan diversos lenguajes, marcos de trabajo e infraestructura como código que requieren analizadores especializados, no hay ningún analizador único que detecte todas las clases de vulnerabilidad. Las estrategias SAST multicapa que combinan herramientas especializadas con ejecución automática y puertas de calidad garantizan una cobertura completa al mismo tiempo que proporcionan a los desarrolladores comentarios inmediatos cuando se detectan problemas de seguridad.

Implemente pruebas de seguridad automatizadas con estos componentes:

  • Implemente la estrategia de examen de varias capas: Inserte pruebas automatizadas de seguridad de aplicaciones estáticas en cada compilación para detectar vulnerabilidades antes de que el código llegue a producción. Implemente una estrategia SAST de varias capas que combina varios escáneres especializados, sin una sola herramienta detecta todas las clases de vulnerabilidad, por lo que una cobertura completa requiere analizadores específicos del lenguaje (Python, JavaScript, C/C++), escáneres de infraestructura como código (Terraform, plantillas de ARM, manifiestos de Kubernetes), detección de secretos y análisis de código semántico para vulnerabilidades complejas de flujo de datos.

  • Configurar la ejecución automática con puertas de calidad: Configure el examen de SAST para que se ejecute automáticamente en cada confirmación y solicitud de incorporación de cambios, lo que proporciona a los desarrolladores comentarios inmediatos sobre los problemas de seguridad mientras el contexto del código está actualizado. Establezca puertas de calidad basadas en gravedad que bloqueen las combinaciones o implementaciones cuando se detecten vulnerabilidades críticas o de alta gravedad, lo que impide que el código vulnerable avance a través de la canalización. Configure escáneres para generar resultados en formatos estandarizados (SARIF) que permitan un seguimiento de vulnerabilidades coherente, desduplicación entre herramientas e integración con paneles de seguridad centralizados.

  • Implemente el escaneo de secretos con protección de inserción: Implemente un análisis especializado que impida a los desarrolladores comprometer credenciales, claves de API, certificados o tokens en los repositorios, detectando secretos en el momento de la confirmación en lugar de descubrirlos en las auditorías semanas después. Admite patrones de secreto estándar (claves de AWS, tokens de Azure, cadenas de conexión de base de datos) y patrones personalizados específicos de la organización para mecanismos de autenticación propietarios. Cuando se detectan secretos, proporcione instrucciones de corrección inmediatas, incluidos los procedimientos de rotación de credenciales y las alternativas seguras.

  • Use el análisis de código semántico para vulnerabilidades complejas: Implemente herramientas de análisis de código semántico como GitHub CodeQL que realizan análisis profundos del flujo de datos para identificar vulnerabilidades complejas invisibles para escáneres de coincidencia de patrones, como la inyección de código SQL a través de varias llamadas de función, omisión de autenticación en lógica de negocios o cadenas de deserialización no seguras. Cree consultas de seguridad personalizadas adaptadas a los marcos, los requisitos de seguridad y los patrones de vulnerabilidad comunes identificados en las retrospectivas de incidentes. Integre los resultados de SAST directamente en los flujos de trabajo de los desarrolladores a través de comentarios de pull requests con números de línea específicos, explicaciones de vulnerabilidades y recomendaciones de corrección.

  • Orquestación con plataformas unificadas: Las plataformas SAST unificadas como La extensión de DevOps de seguridad de Microsoft pueden organizar varios escáneres especializados (AntiMalware, Bandit, BinSkim, Checkov, ESLint, Template Analyzer, Terrascan, Trivy) a través de una sola tarea de canalización, estandarizar la administración de la configuración y la agregación de resultados en ecosistemas heterogéneos de herramientas.

Ejemplo de implementación

Un proveedor de SaaS sufrió un ataque por inyección de CÓDIGO SQL que expone cientos de miles de registros de clientes. El análisis posterior al incidente reveló amplias vulnerabilidades de nivel de código, incluidas las credenciales codificadas de forma rígida y los errores de inyección que existían durante meses.

Desafío: Las revisiones manuales de código detectaron solo una pequeña fracción de vulnerabilidades. Los desarrolladores no tienen formación en seguridad para identificar fallos de inyección y debilidades criptográficas. No se realiza escaneo automatizado antes de la implementación en producción.

Enfoque de solución:

  • SAST de varios escáneres: Se implementó la extensión de Microsoft Security DevOps con CodeQL, ESLint y Bandit, lo que proporciona una cobertura completa en diferentes lenguajes de programación y tipos de vulnerabilidad.
  • Protección de secretos: Se implementó Seguridad avanzada de GitHub con examen de secretos y protección de inserción que impide la exposición de credenciales en confirmaciones.
  • Análisis semántico: Se ha configurado GitHub CodeQL con consultas personalizadas para vulnerabilidades de lógica empresarial y patrones de seguridad específicos del marco.
  • Puertas de seguridad: Puertas de canalización establecidas en Azure Pipelines que bloquean la implementación de hallazgos de alta gravedad.

Resultado: Se han identificado y corregido rápidamente las amplias vulnerabilidades. Se impidió que los errores críticos de seguridad llegaran a la producción. Deuda de seguridad considerablemente reducida.

Nivel de importancia crítica

Imprescindible.

Asignación de controles

  • NIST SP 800-53 Rev.5: SA-11, RA-5, SI-2
  • PCI-DSS v4: 6.3.2, 6.4.1, 11.3.1
  • Cis Controls v8.1: 16.3, 16.6
  • NIST CSF v2.0: PR.IP-2, DE.CM-4
  • ISO 27001:2022: A.8.25, A.8.29
  • SOC 2: CC7.1, CC7.2

DS-5: Integración de pruebas dinámicas de seguridad de aplicaciones (DAST)

Principio de seguridad

Implemente pruebas completas de seguridad dinámica en entornos de preproducción a través del análisis de seguridad de contenedores para cargas de trabajo en contenedores, pruebas de penetración automatizadas para aplicaciones web e interfaces de programación de aplicaciones (API) y pruebas especializadas para la autenticación, autorización y administración de sesiones. La validación en tiempo de ejecución identifica los puntos débiles de configuración y las vulnerabilidades de integración que el análisis estático no puede detectar.

Riesgo para mitigar

Las vulnerabilidades en tiempo de ejecución que son invisibles para el análisis estático crean brechas de seguridad críticas que los adversarios aprovechan después de implementar las aplicaciones. Sin DAST completo:

  • Puntos débiles de configuración de implementación: Proveedores de autenticación mal configurados, configuraciones permisivas de CORS, configuraciones débiles de TLS o la falta de encabezados de seguridad (CSP, HSTS, X-Frame-Options) permiten ataques que no pueden ser detectados por la revisión de código origen.
  • Brechas de seguridad de API: Las API REST y GraphQL con omisión de autenticación, errores de autorización, exposición excesiva de datos, limitación de velocidad que falta o referencias a objetos directos no seguros (IDOR) permiten el acceso no autorizado y la extracción de datos.
  • Omisións de autenticación y autorización: Los errores en la administración de sesiones, los flujos de restablecimiento de contraseña, la implementación de la autenticación multifactor o la lógica de control de acceso basado en rol permiten la elevación de privilegios y la adquisición de cuentas.
  • Vulnerabilidades de administración de sesiones: Tokens de sesión predecibles, aplicación de tiempo de espera insuficiente, vulnerabilidades de fijación de sesión, o falta de revocación de tokens habilitan el secuestro de la sesión y el robo de credenciales.
  • Problemas de seguridad específicos del entorno: Los puntos de integración con bases de datos, colas de mensajes, API externas o servicios de terceros presentan vulnerabilidades en tiempo de ejecución invisibles en las pruebas de desarrollo o aisladas.
  • Errores de lógica empresarial: Las condiciones de carrera, las vulnerabilidades de manipulación del estado, la validación insuficiente de entradas en flujos de trabajo complejos o los problemas de integridad de transacciones permiten el fraude y la manipulación de datos.

DAST valida el comportamiento en tiempo de ejecución, la configuración del entorno y la seguridad de la integración proporcionando una cobertura que el análisis estático no puede ofrecer.

MITRE ATT&CK

  • Acceso inicial (TA0001): aprovechar la aplicación orientada al público (T1190) aprovechando las omisións de autenticación, los errores de inyección o los puntos de conexión de API no seguros detectados a través de pruebas en tiempo de ejecución.
  • Acceso a credenciales (TA0006): fuerza bruta (T1110) que explota la falta de limitación de velocidad, políticas de contraseñas débiles o tokens de sesión predecibles detectados durante DAST.
  • Elevación de privilegios (TA0004): cuentas válidas (T1078) que explotan las vulnerabilidades de autorización o manipulación de roles en las aplicaciones implementadas.
  • Colección (TA0009): datos de repositorios de información (T1213) que extraen datos confidenciales mediante respuestas excesivas de API, vulnerabilidades de recorrido de directorios o referencias inseguras a objetos directos.
  • Filtración (TA0010): filtración a través del servicio web (T1567) que aprovecha las brechas de seguridad de la API para extraer datos a escala sin detección.

DS-5.1: Implementar DAST automatizado en preproducción

Las pruebas dinámicas de seguridad de aplicaciones validan los controles de seguridad en aplicaciones en ejecución, detectando vulnerabilidades en tiempo de ejecución que el análisis estático no puede detectar. Aunque SAST examina el código fuente, las pruebas DAST implementan aplicaciones con configuraciones similares a producción para identificar problemas específicos de la implementación, incluidas las configuraciones incorrectas de autenticación, los errores de autorización y las brechas de seguridad de integración que solo se manifiestan en entornos operativos. DAST automatizado en preproducción garantiza la validación de seguridad antes de exponer los sistemas a los clientes, probando escenarios de ataque realistas en sistemas completamente integrados.

Implemente la validación de seguridad en tiempo de ejecución mediante estas funcionalidades:

  • Complementar SAST con validación en tiempo de ejecución: Complemente el análisis estático con pruebas dinámicas de seguridad de aplicaciones que validan la seguridad en las aplicaciones en ejecución con configuraciones similares a producción. Aunque SAST identifica vulnerabilidades en el código fuente, DAST detecta problemas en tiempo de ejecución invisibles para el análisis estático: puntos débiles de configuración de implementación (proveedores de autenticación mal configurados, directivas CORS permisivas, encabezados de seguridad que faltan), errores de integración específicos del entorno (seguridad de la conexión de base de datos, autorización de API en contextos implementados) y vulnerabilidades de lógica de negocios que solo se manifiestan en condiciones operativas realistas.

  • Implementación en entornos de ensayo similares a la producción: Implemente el examen de DAST en entornos de ensayo de preproducción que reflejen la arquitectura de producción, la topología de red, las dependencias externas y los parámetros de configuración. La ejecución automatizada de DAST debe desencadenarse en la implementación en el entorno de pruebas, probando sistemáticamente los flujos de autenticación, límites de autorización, gestión de sesiones, validación de entradas, seguridad de la interfaz de programación de aplicaciones y manejo de errores bajo patrones de carga y uso realistas. Esto valida que los controles de seguridad funcionan correctamente cuando se integran con sistemas externos similares a producción (proveedores de identidades, bases de datos, colas de mensajes, API de terceros).

  • Implemente la supervisión en tiempo de ejecución para contenedores: En el caso de las cargas de trabajo en contenedor, implemente la supervisión continua de la seguridad en tiempo de ejecución que combina el análisis de imágenes anteriores a la implementación con el análisis de comportamiento posterior a la implementación. Examine las imágenes de contenedor para detectar vulnerabilidades conocidas antes de la implementación y, a continuación, supervise la ejecución de contenedores para las conexiones de red anómalas, la ejecución de procesos no autorizados, las modificaciones del sistema de archivos y los intentos de escalación de privilegios. Generar perfiles del comportamiento normal de la carga de trabajo de Kubernetes para detectar desviaciones que indican el riesgo y evaluar continuamente las configuraciones de contenedor en comparación con las pruebas comparativas de CIS y los procedimientos recomendados de seguridad.

  • Céntrese en superficies de ataque de alto riesgo: Céntrese en los esfuerzos especializados de DAST en superficies de ataque de alto riesgo: REST y GraphQL API (omisión de autenticación de prueba, errores de autorización, vulnerabilidades de inyección, exposición excesiva de datos, referencias a objetos directos no seguros), autenticación y administración de sesiones (valide la seguridad del token, aplicación de tiempo de espera, funcionalidad de cierre de sesión, flujos de restablecimiento de contraseña, autenticación multifactor) y flujos de trabajo de lógica empresarial (pruebas para condiciones de carrera, manipulación de estado, problemas de integridad de transacciones). Establezca flujos de trabajo de correlación de SAST/DAST que combinen los resultados de ambos enfoques, priorizando las vulnerabilidades confirmadas a través del análisis estático y dinámico como riesgo más alto.

  • Aprovechar las plataformas integradas: Para entornos en contenedores, Microsoft Defender for Containers proporciona funcionalidades integradas de evaluación de vulnerabilidades en tiempo de ejecución, generación de perfiles de cargas de trabajo y detección de amenazas a lo largo del ciclo de vida del contenedor.

Ejemplo de implementación

Una organización de comercio electrónico detectó la omisión de autenticación en la API de pago, lo que permite descuentos no autorizados. SAST perdió el error de configuración en tiempo de ejecución que solo se manifiesta en entornos implementados con proveedores de autenticación externos.

Desafío: SAST detectó vulnerabilidades de código, pero no detectó problemas de configuración en tiempo de ejecución y fallos de autorización de API. La configuración de implementación de producción difiere de la utilizada en desarrollo, creando brechas de seguridad que pasan desapercibidas en el análisis estático.

Enfoque de solución:

  • Examen automatizado de DAST: Se implementó OWASP ZAP en entornos de preproducción que prueban aplicaciones implementadas con configuraciones similares a la producción.
  • Protección en tiempo de ejecución del contenedor: Se ha implementado Microsoft Defender for Containers para la supervisión de la seguridad en tiempo de ejecución y la evaluación de vulnerabilidades.
  • Pruebas de seguridad de API: Se han configurado pruebas de API especializadas que validan la autenticación, la autorización y la validación de datos en puntos de conexión REST y GraphQL implementados.
  • Correlación de SAST/DAST: Se crearon flujos de trabajo de correlación de vulnerabilidades que combinan resultados estáticos y dinámicos para una validación de seguridad completa.

Resultado: Se detectaron vulnerabilidades en tiempo de ejecución no detectadas por SAST, incluidas las omisiones de autenticación y los fallos de autorización de API. Los incidentes de seguridad fueron prevenidos mediante la detección en preproducción.

Nivel de importancia crítica

Imprescindible.

Asignación de controles

  • NIST SP 800-53 Rev.5: SA-11, CA-8, RA-5
  • PCI-DSS v4: 6.4.2, 11.3.2
  • Cis Controls v8.1: 16.7, 16.8
  • NIST CSF v2.0: DE.CM-4, PR.IP-12
  • ISO 27001:2022: A.8.29, A.8.30
  • SOC 2: CC7.1, CC7.3

DS-6: Protección del ciclo de vida de la carga de trabajo

Azure Policy: Consulte Definiciones de directivas integradas de Azure: DS-6.

Principio de seguridad

Implemente una infraestructura inmutable con seguridad de imagen completa a través de registros de contenedores y análisis de seguridad para cargas de trabajo de contenedores, administración de imágenes maestras y creación automatizada para cargas de trabajo de máquinas virtuales (VM), análisis continuo de vulnerabilidades con cuarentena automatizada. Verifique las firmas criptográficas, mantenga de manera mínima las imágenes base y refuerce las líneas base de seguridad a lo largo del ciclo de vida de la carga de trabajo.

Riesgo para mitigar

La gestión del ciclo de vida de cargas de trabajo inseguras permite que los artefactos vulnerables o comprometidos lleguen a producción, creando vectores de ataque persistentes que los atacantes explotan sistemáticamente. Sin seguridad completa de la carga de trabajo:

  • Imágenes de máquina virtual de producción vulnerables: Las líneas base del sistema operativo no configuradas o las imágenes doradas mal configuradas propagan puntos débiles en todas las máquinas virtuales implementadas.
  • Imágenes base vulnerables no parcheadas: Contenedores que utilizan imágenes base afectadas por CVE (Log4Shell, Heartbleed, OpenSSL) exponen cargas de trabajo a vulnerabilidades de explotación y escape.
  • Artefactos vulnerables obsoletos: Las imágenes y los paquetes sin ser escaneados acumulan CVEs, expandiendo la superficie de ataque.
  • Comprobación insuficiente de la imagen: La falta de firma criptográfica y validación de procedencia permite a los adversarios sustituir imágenes legítimas por versiones en peligro que contienen puertas traseras o malware.
  • Superficie expuesta a ataques sobredimensionada: Las imágenes de contenedor que contienen paquetes innecesarios, herramientas de desarrollo o utilidades de depuración aumentan la exposición a vulnerabilidades y proporcionan a los atacantes herramientas de explotación adicionales.
  • Faltan líneas base de seguridad: Las imágenes de máquina virtual y contenedor implementadas sin el cumplimiento de puntos de referencia CIS, el refuerzo de la seguridad o la configuración de privilegios mínimos crean brechas que pueden ser aprovechadas en la defensa en profundidad.

Los artefactos comprometidos se convierten en vectores de ataque persistentes, ayudan al movimiento lateral y aparecen legítimos para los defensores.

MITRE ATT&CK

  • Acceso inicial (TA0001): explotar vulnerabilidades sin parchear en aplicaciones orientadas al público (T1190) aprovechando vulnerabilidades en contenedores de aplicaciones o servicios web.
  • Ejecución (TA0002): implementación del contenedor (T1610) que implementa contenedores malintencionados que aparecen legítimos debido a una comprobación de imagen insuficiente.
  • Escalada de privilegios (TA0004): escape al sistema anfitrión (T1611) que aprovecha las vulnerabilidades del contenedor para interrumpir el aislamiento de contenedores y comprometer el sistema anfitrión.
  • Movimiento lateral (TA0008): explotación de servicios remotos (T1210) pivotando entre máquinas virtuales o contenedores vulnerables implementados a partir de imágenes comprometidas.

DS-6.1: Implementar la seguridad de la imagen de contenedor

Las imágenes de contenedor y máquina virtual representan superficies de ataque críticas que requieren controles de seguridad completos a lo largo de su ciclo de vida. Las imágenes base vulnerables propagan debilidades a todas las instancias implementadas, lo que amplifica el impacto en toda la infraestructura. Tratar los artefactos de carga de trabajo con el mismo rigor de seguridad que el código fuente, incluido el examen, la firma y el almacenamiento protegido, garantiza que las organizaciones implementen solo imágenes comprobadas y confiables, a la vez que impiden que los atacantes aprovechen vulnerabilidades conocidas o sustituya imágenes malintencionadas.

Asegure los componentes de carga de trabajo con las siguientes prácticas:

  • Establecer principios de infraestructura inmutable: Trate las imágenes de contenedor y las imágenes de máquina virtual como artefactos críticos que requieren el mismo rigor de seguridad que el código fuente, ya que las imágenes base vulnerables propagan debilidades a cada instancia desplegada. Establezca principios de infraestructura inmutables en los que los artefactos de carga de trabajo se construyen una vez, se examinan exhaustivamente, se firman criptográficamente e implementan sin modificación para garantizar la coherencia y la trazabilidad durante todo el ciclo de vida.

  • Utilice imágenes base mínimas con construcciones de varias etapas: En el caso de las cargas de trabajo de contenedores, implemente la seguridad de imágenes en capas a partir de imágenes base mínimas que contengan solo componentes esenciales en tiempo de ejecución, lo que reduce drásticamente la superficie de ataque en comparación con las imágenes completas del sistema operativo. Use compilaciones de varias fases para separar las dependencias de compilación de las imágenes de ejecución. Compile y construya en imágenes con muchas funcionalidades, después copie solo los artefactos finales en imágenes mínimas de ejecución, eliminando herramientas de desarrollo, gestores de paquetes y dependencias de compilación que incrementan la exposición a vulnerabilidades y proporcionan a los atacantes herramientas para la explotación de dichas vulnerabilidades.

  • Integre el examen automatizado con directivas de cuarentena: Integre el examen automatizado de vulnerabilidades en la canalización de compilación de imágenes que examina todas las imágenes antes del almacenamiento del Registro, comprobando las bases de datos CVE completas y revisando continuamente las imágenes almacenadas a medida que se divulgan nuevas vulnerabilidades. Implemente directivas de cuarentena automatizadas que impidan que las imágenes con vulnerabilidades críticas o de alta gravedad se implementen, con flujos de trabajo de excepción que requieren aprobación del equipo de seguridad y aceptación de riesgos documentados. Establezca políticas de actualización de imágenes base con desencadenadores automatizados en la canalización cuando se publiquen revisiones de seguridad, garantizando que las imágenes no acumulen CVE con el tiempo.

  • Exigir la firma y verificación criptográficas: Implemente la integridad de la imagen mediante la firma y verificación criptográficas en cada etapa: firme las imágenes en tiempo de compilación, verifique las firmas antes del despliegue y rechace automáticamente las imágenes sin firmar o manipuladas. Esto evita ataques de sustitución de imágenes en los que los adversarios reemplazan las imágenes legítimas por versiones en peligro que contienen puertas traseras. Almacene imágenes en registros de contenedor protegidos con controles de acceso a la red (puntos de conexión privados, integración de red virtual), directivas de acceso basadas en rol que limiten quién puede insertar o extraer imágenes y un registro de auditoría completo de todas las operaciones del Registro.

  • Mantenimiento de imágenes doradas fortalecidas para máquinas virtuales: En el caso de las cargas de trabajo de máquina virtual, mantenga repositorios centralizados de imágenes doradas con imágenes base compatibles con los estándares de referencia de CIS que se someten a aplicación de parches de seguridad periódica y validación de cumplimiento. Implemente canalizaciones de creación de imágenes automatizadas que incorporen actualizaciones de seguridad, quiten servicios innecesarios, apliquen configuraciones con privilegios mínimos y generen imágenes nuevas en programaciones definidas en lugar de aplicar revisiones a sistemas en ejecución.

  • Aproveche las plataformas de seguridad integradas: Las soluciones como Azure Container Registry con la integración de Microsoft Defender para contenedores proporcionan análisis automatizado, flujos de trabajo de cuarentena, confianza de contenido y replicación de varias regiones con directivas de seguridad coherentes.

Ejemplo de implementación

Una organización logística implementó una aplicación contenedora con una imagen base sin revisión que contiene una vulnerabilidad crítica de ejecución remota de código. Los atacantes aprovecharon la vulnerabilidad poco después de la implementación, poniendo en peligro los datos de envío.

Desafío: Numerosas imágenes de contenedor sin análisis de vulnerabilidades. Las imágenes creadas hace meses acumulaban muchas CVE, incluidas las vulnerabilidades críticas. Ninguna comprobación impedía la sustitución de imágenes malintencionadas.

Enfoque de solución:

  • Seguridad del registro de contenedor: Se implementó Azure Container Registry con análisis de vulnerabilidades para poner en cuarentena imágenes con CVEs de alta gravedad antes de la implementación.
  • Imágenes de máquina virtual protegidas: Ha implementado Azure Shared Image Gallery con imágenes de máquina virtual compatibles con pruebas comparativas de CIS para cargas de trabajo reguladas.
  • Protección en tiempo de ejecución: Configurado Microsoft Defender para contenedores para la detección continua de amenazas y el monitoreo de desviaciones.
  • Integridad del artefacto: Se estableció la firma criptográfica y la comprobación, lo que garantiza la autenticidad de la imagen a lo largo del ciclo de vida.

Resultado: Se bloquearon las imágenes vulnerables del despliegue de producción. Se ha reducido drásticamente el número de CVE de contenedor por imagen. Se evitaron ataques de sustitución de imágenes a través de la comprobación de firmas.

Nivel de importancia crítica

Imprescindible.

Asignación de controles

  • NIST SP 800-53 Rev.5: CM-2, CM-3, SI-2, SI-7, RA-5
  • PCI-DSS v4: 6.2.4, 6.3.3, 11.3.1
  • Cis Controls v8.1: 4.1, 7.3, 7.4
  • NIST CSF v2.0: PR.IP-1, PR.IP-3, DE.CM-8
  • ISO 27001:2022: A.8.9, A.8.31, A.8.32
  • SOC 2: CC7.2, CC8.1

DS-7: Implementación del registro y la supervisión de DevOps

Principio de seguridad

Implemente un registro completo de actividades de DevOps a través del streaming de auditoría con integración en plataformas centralizadas de administración de eventos e información de seguridad (SIEM) para el análisis de seguridad, la detección de amenazas en tiempo real y la respuesta automatizada. Establezca análisis de comportamiento, detección de anomalías y métricas de seguridad para habilitar la respuesta rápida a incidentes y mantener los seguimientos de auditoría de cumplimiento.

Riesgo para mitigar

El registro y la supervisión de DevOps insuficientes crean puntos ciegos críticos que los adversarios aprovechan para operar sin detectar, establecer persistencia y filtrar código o credenciales confidenciales. Sin visibilidad completa:

  • Compromisos de canalización no detectados: Los atacantes modifican las canalizaciones de CI/CD para insertar código malintencionado, filtrar secretos o establecer puertas traseras sin desencadenar alertas debido a un registro de auditoría ausente o insuficiente.
  • Amenazas internas que modifican código o infraestructura: Los usuarios internos malintencionados o las cuentas en peligro realizan cambios no autorizados en el código fuente, las definiciones de infraestructura o las configuraciones de implementación sin detección.
  • Falta de seguimientos de auditoría completos: La ausencia de registros de actividad detallados impide la investigación forense, la evaluación del impacto y el análisis de la causa principal cuando se producen incidentes de seguridad que prolongan el tiempo de permanencia y aumentan el impacto en las infracciones.
  • Respuesta a incidentes retrasadas: El tiempo medio para detectar (MTTD) se extiende de horas a semanas cuando los equipos de seguridad carecen de alertas en tiempo real, detección de anomalías y correlación automatizada de eventos de seguridad de DevOps.
  • Errores de auditoría de cumplimiento: Los requisitos normativos (SOX, PCI-DSS, HIPAA, ISO 27001) que exigen seguimientos de auditoría completos, seguimiento de cambios y registro de acceso no se pueden cumplir sin la supervisión centralizada de DevOps.
  • Ceguera en la escalada de privilegios: La elevación no autorizada de permisos, la creación de cuentas de acceso alternativo o la modificación de los controles de acceso continúan sin detectarse sin análisis de comportamiento y supervisión de privilegios.

Las brechas de registro ocultan los cambios de canalización malintencionados, la elevación de privilegios y los intentos de acceso persistente en caminos de desarrollo con privilegios elevados.

MITRE ATT&CK

  • Evasión de defensa (TA0005): afecta a las defensas (T1562) deshabilitando el registro de auditoría, los pasos de examen de seguridad o los agentes de supervisión para operar en puntos ciegos y la eliminación de indicadores (T1070) borrando los registros de auditoría o el historial de ejecución de canalizaciones para ocultar actividades malintencionadas.
  • Persistencia (TA0003): manipulación de cuentas (T1098) que crea principales de servicio adicionales, tokens de acceso personal o claves SSH de manera no detectada.
  • Recopilación (TA0009): datos de repositorios de información (T1213) exfiltrando código fuente, secretos o propiedad intelectual a través del acceso a un canal de comunicación.
  • Acceso a credenciales (TA0006): credenciales no seguras (T1552) que permiten recopilar secretos expuestos de registros de canalización o historial de ejecución.

DS-7.1: Implementación del registro de auditoría para plataformas de DevOps

Las plataformas de DevOps con acceso con privilegios a la infraestructura de producción y el código fuente confidencial requieren una supervisión de seguridad completa para detectar actividades de adversarios y amenazas internas. Las brechas de registro de auditoría permiten a los actores malintencionados operar sin detectar durante períodos prolongados, mientras que la agregación centralizada de registros permite la correlación con una telemetría de seguridad más amplia que revela cadenas de ataque sofisticadas. El análisis de comportamiento en tiempo real identifica patrones sospechosos invisibles en eventos aislados, lo que transforma los datos de auditoría sin procesar en inteligencia de seguridad accionable.

Establezca una supervisión completa de la seguridad de DevOps mediante estas funcionalidades:

  • Capture actividades completas relevantes para la seguridad: Establezca un registro de auditoría completo que capture todas las actividades de DevOps pertinentes para la seguridad: eventos de autenticación y autorización de usuarios, confirmaciones de código fuente y operaciones de rama, creación y modificación de canalizaciones, ejecuciones de implementación, acceso secreto, cambios de permisos, creación de entidades de servicio y acciones administrativas. Las plataformas de DevOps tienen acceso con privilegios a la infraestructura de producción y las brechas de registro de código confidenciales permiten que los adversarios y los usuarios internos malintencionados funcionen sin detectar durante períodos prolongados.

  • Reenvíe los registros a SIEM centralizado en tiempo real: Reenvíe los registros de auditoría en tiempo real a plataformas SIEM centralizadas en lugar de confiar en la retención nativa de la plataforma DevOps (normalmente 90 días), lo que permite el análisis forense a largo plazo, los informes de cumplimiento y la correlación con eventos de seguridad de otros sistemas. Transmita registros a centros de operaciones de seguridad a través de protocolos estandarizados (/azure Event Hubs, syslog) en formatos estructurados (JSON) que permiten el análisis automatizado, el análisis y las alertas sin revisión manual del registro.

  • Implemente análisis de comportamiento y detección de anomalías: Implemente análisis de comportamiento y detección de anomalías en los datos de auditoría de DevOps para identificar patrones sospechosos invisibles en eventos individuales: modificaciones de canalización fuera del horario laboral, acceso inusual a repositorios confidenciales, escalaciones de privilegios rápidas, creación de entidades de servicio seguidas de implementaciones sospechosas, ejecuciones de canalizaciones desde ubicaciones inesperadas o patrones anómalos de acceso secreto. Establecer perfiles de comportamiento de línea base para usuarios y servicios, alertando sobre desviaciones estadísticamente significativas que pueden indicar riesgos o amenazas internas.

  • Configurar alertas automatizadas para actividades de alto riesgo: Configure alertas automatizadas para actividades de alto riesgo con notificaciones inmediatas a los equipos de seguridad: errores de implementación de producción, modificaciones de canalización en ramas protegidas, nueva creación de entidad de servicio, eventos de elevación de permisos, pasos de examen de seguridad deshabilitados, cambios de configuración de reenvío de registros de auditoría o intentos de acceso a secretos de canalizaciones no autorizadas. Implemente la escalación basada en gravedad, lo que garantiza que las alertas críticas alcancen las operaciones de seguridad inmediatamente mientras los eventos rutinarios se procesan por lotes para su análisis.

  • Integración con telemetría de seguridad más amplia: Integre los registros de auditoría de DevOps con telemetría de seguridad más amplia en plataformas SIEM para la correlación con la detección de puntos de conexión, la seguridad de red, los eventos de identidad y las fuentes de inteligencia sobre amenazas. Esto permite la detección de cadenas de ataque sofisticadas en las que el compromiso de DevOps es una fase en operaciones multifase; por ejemplo, la correlación de credenciales suplantadas con modificaciones subsiguientes de canalización y aprovisionamiento inusual de recursos en la nube.

  • Aproveche las plataformas SIEM integradas: Las plataformas como Azure DevOps Audit Streaming con la integración de Microsoft Sentinel proporcionan reenvío de registros en tiempo real, reglas de detección pregeneradas para amenazas de DevOps, libros de seguridad para la investigación y orquestación de respuesta automatizada.

Ejemplo de implementación

Una organización de manufactura detectó una amenaza interna cuando un antiguo contratista modificó la canalización de CI/CD inyectando código de puerta trasera dentro de la aplicación en producción. El incidente no se detectó durante meses debido a un registro de auditoría insuficiente.

Desafiar: No hay registro centralizado de actividades de DevOps. Las modificaciones de canalización y los cambios en el acceso privilegiado no han sido supervisados. La investigación forense fue obstaculizada por la falta de registros de auditoría. No se pudo realizar la auditoría de cumplimiento debido a un seguimiento de cambios insuficiente.

Enfoque de solución:

  • Registro de auditoría centralizado: Se habilitó el reenvío de eventos de Azure DevOps Audit Streaming a Microsoft Sentinel para el análisis de seguridad y la retención a largo plazo.
  • Análisis de comportamiento: Se implementó la detección de anomalías que identifica patrones de acceso inusuales, modificaciones de canalización fuera del horario laboral y escalaciones de privilegios que indican amenazas internas.
  • Alertas automatizadas: Alertas configuradas para actividades sospechosas, incluidas implementaciones de producción no autorizadas y enrutamiento de creación de entidades de servicio a operaciones de seguridad.
  • Informes de cumplimiento: Se ha creado una generación automatizada de registros de auditoría que cumpla los requisitos normativos con un seguimiento de cambios completo.

Resultado: Se detectó e impedía modificaciones posteriores de canalizaciones no autorizadas rápidamente. Se ha reducido considerablemente el tiempo de investigación de incidentes con seguimientos de auditoría completos. Se ha logrado la conformidad con la gestión de cambios documentados.

Nivel de importancia crítica

Debería tenerlo.

Asignación de controles

  • NIST SP 800-53 Rev.5: AU-2, AU-3, AU-6, AU-12, SI-4
  • PCI-DSS v4: 10.2.1, 10.2.2, 10.3.4
  • Cis Controls v8.1: 8.2, 8.5, 8.11
  • NIST CSF v2.0: DE.CM-1, DE.CM-7, RS.AN-1
  • ISO 27001:2022: A.8.15, A.8.16
  • SOC 2: CC7.2, CC7.3
  • Last updated on