Compartir a través de

Controles de DevSecOps

  • Artículo

En este artículo se describe cómo aplicar controles de seguridad para admitir las prácticas de seguridad de SDL continuas. Estos controles de seguridad son una parte integral de una estrategia de DevSecOps que abarca personas, procesos y tecnología. En esta documentación se describe cada control y se muestra cómo aplicar estos controles a tres perfiles de seguridad. Estos perfiles cumplen los requisitos de seguridad habituales para escenarios empresariales comunes en la mayoría de las organizaciones:

Diagrama de controles de seguridad según el tiempo y el impacto.

Perfiles de control de seguridad

Hay tres niveles de perfiles de control a los que se hace referencia en este artículo.

Mínimo temporal: perfil de seguridad abreviado para un estado de excepción temporal para admitir la creación rápida de prototipos de cargas de trabajo de bajo riesgo. Este perfil debe usarse únicamente para excepciones temporales que deban publicarse en una escala de tiempo acelerada para satisfacer las necesidades empresariales críticas. Los elementos que usan este perfil deben aparecer rápidamente en el perfil estándar.

Estándar: enfoque equilibrado para la mayoría de las cargas de trabajo, la mayor parte del tiempo.

Alta seguridad: seguridad estricta para cargas de trabajo con un posible impacto alto en la seguridad empresarial y humana.

Controles de seguridad de DevSecOps

En esta sección se proporciona una referencia de los controles de seguridad recomendados para cada tipo de carga de trabajo. Esta referencia puede adoptarse tal cual o puede adaptarse a los procesos existentes de desarrollo de software y seguridad de software. La mayoría de las organizaciones no pueden implementar todos estos controles inmediatamente si aún no están siguiendo algunos de ellos. Adoptar un enfoque de mejora continua suele ser lo mejor: priorizar los controles, implementar el primer control, pasar al siguiente control, implementarlo, etc. La mayoría de las organizaciones deben priorizar primero las bases críticas.

Para obtener más información, consulte la Recorrido por DevSecOps.

En este diagrama se resumen los controles de seguridad y cómo aplicarlos a cada perfil de seguridad de carga de trabajo.

Entre las consideraciones de planeamiento clave se incluyen:

  • Desplazamiento a la izquierda pero compruébelo bien - Esta referencia está diseñada para detectar y corregir problemas tan pronto como sea posible para permitirle corregirlos cuando sea más fácil y económico corregir los problemas (a veces denominado prueba de desplazamiento a la izquierda), pero también para asumir errores e incluir la comprobación doble más adelante en el proceso. Compruebe siempre los controles de seguridad en el proceso de CI/CD, asegúrese de que los problemas evitables no pasan a los sistemas de producción. Este concepto sigue los principios de "defensa profunda" y "fallo seguro".
  • Inteligencia artificial (IA): las dos implicaciones principales de la inteligencia artificial son:
    • Proteger todo el código independientemente de si está escrito por la IA humana o generativa
    • Uso de ambos para la seguridad: aplica controles clásicos e IA como disponibles para aumentar la visibilidad y el contexto de los problemas de seguridad (como las herramientas de análisis de código).

Controles de seguridad

Los controles se agrupan en las fases de desarrollo a los que se aplican y a los controles comunes (bases críticas) que se aplican en todas las fases de desarrollo y perfiles de control:

Cada uno de estos elementos se define en las secciones siguientes:

Establecer bases críticas

Este control admite la Práctica continua de SDL 1: establecer estándares de seguridad, métricas y gobernanza, práctica 2: requerir el uso de características de seguridad probadas, lenguajes y marcos, y práctica 10: proporcionar formación de seguridad.

Estándar: estos controles se aplican en todas las fases de desarrollo y perfiles de control.

Proporcionar formación de seguridad

Este control se centra en proporcionar a las personas con roles de desarrollo y equipos de seguridad formación para reconocer y resolver problemas de seguridad con el ciclo de vida de desarrollo. Sin la formación de seguridad, los equipos podrían perder los puntos débiles de seguridad principales que conducen a riesgos durante la vigencia de las aplicaciones.

Como resultado, es imperativo implementar la formación de seguridad en todos los roles (incluidos personas usuarias, desarrolladoras, administradoras de línea de productos, evaluadoras, etc.). Cada rol debe tener formación sobre los riesgos de seguridad y su rol para mantener las aplicaciones seguras. Esta formación puede adoptar la forma de: formación formal o a petición, ejercicios de simulación, modelos de riesgos, mentoría/asesores, personas expertas en seguridad, equipos de soporte técnico de seguridad de aplicaciones, actividades de equipo púrpura, podcasts, vídeos o cualquier otro método de aprendizaje.

En última instancia, cada rol debe comprender lo siguiente:

  • Por qué es importante abordar los riesgos de seguridad
  • Qué deben hacer para mentener la seguridad en su rol
  • Cómo hacer que la seguridad forme parte de sus funciones diarias

Las personas que comprendan la perspectiva del atacante, sus objetivos y cómo se muestran en incidentes de seguridad del mundo real se convierten rápidamente en defensores de seguridad en lugar de intentar evitarla.

La seguridad es un juego sin fin en el que las amenazas, la tecnología y los recursos empresariales que se van a proteger siempre cambian y los actores de amenazas nunca se detienen. El enfoque de formación de seguridad debe estar en curso y evolucionar continuamente. La formación eficaz se alinea y se refuerza las directivas de seguridad, los procedimientos del ciclo de vida de desarrollo de software (SDL), los estándares y los requisitos de seguridad de software. El material de formación debe provenir de información derivada de los datos y las funcionalidades técnicas recién disponibles.

Aunque la seguridad es un trabajo que recae en todos los usuarios, cabe recordar que no todos deben ser expertos en seguridad ni esforzarse en llegar a ser un evaluador de pruebas de penetración experto. Asegurarse de que todo el mundo comprenda los conceptos básicos de seguridad y cómo aplicarlos a su rol para fomentar la creación de seguridad en software y servicios es esencial. Esta formación debe incluir el uso seguro de estaciones de trabajo, aplicaciones, identidades y cuentas.

En concreto, las personas con roles de desarrollo e ingeniería que crean sistemas no suelen ser personas expertas en seguridad. La formación en los aspectos técnicos y conceptuales del modelo de riesgos es necesario para que sean eficaces para que puedan crear sistemas seguros por diseño. Esta formación es fundamental para que el proceso de modelo de riesgos funcione a escala en organizaciones en las que las personas con roles de desarrollo tienen mucho número de profesionales de seguridad. El modelo de riesgos debe considerarse como una aptitud fundamental de ingeniería en la que todas las personas con roles de desarrollo e ingeniería deben tener al menos una competencia básica. Por lo tanto, los equipos de desarrollo e ingeniería deben formarse para ser competentes en el modelo de riesgos como parte de la incorporación y con actualizaciones periódicas.

Inclusión de la seguridad en postmortems sin acusaciones

El análisis postmortem sin acusaciones es un método fundamental e importante para que los equipos aprendan de errores de forma eficaz sin que las personas miembras del equipo se pongan a la defensiva y busquen a alguien a quien culpar. Los aprendizajes de seguridad deben incluirse explícitamente en el proceso postmortem sin acusaciones para asegurarse de que los equipos también sacan el máximo partido de los aprendizajes de seguridad.

Establecimiento de estándares de seguridad, métricas y gobernanza

Las organizaciones deben establecer estos estándares de seguridad, métricas y gobernanza, ya que aumentan la capacidad de innovar. Permite un programa de seguridad sólido que no solo protege los recursos de la organización, sino que también se alinea con sus objetivos de negocio. Los estándares de seguridad son los requisitos de línea base y los procedimientos recomendados para mantener seguros los sistemas, los datos y el proceso de una organización.

Estos estándares deben medirse y controlarse, incluida la supervisión del cumplimiento, y las revisiones y actualizaciones periódicas de amenazas, herramientas y otros factores actuales. Este proceso debe abarcar todo el ciclo de vida de la conceptualización inicial con la retirada de la aplicación y cualquier entorno de desarrollo compatible.

Las métricas son medidas que se usan para ver la eficacia de los controles y procesos de seguridad. Una métrica clave es la Velocidad de corrección a través del tiempo medio para corregir (MTTR) para realizar un seguimiento de cuánto tiempo permanece vulnerable una aplicación. Esta medida nos permite invertir estratégicamente en la emisión de correcciones de seguridad más rápidamente.

Nota:

Este concepto difiere de MTTR en las operaciones de seguridad centradas en el tiempo para eliminar el acceso de un adversario a los recursos de la organización.

La gobernanza de la seguridad actúa como una guía para los equipos de seguridad y a menudo se basa en marcos y procesos que las organizaciones usan para administrar y controlar la seguridad de la información. Estos incluyen directivas, procedimientos, controles y administración de riesgos. Las métricas ayudan a cuantificar la exposición al riesgo. Sin ellos, es posible que la organización no comprenda completamente sus vulnerabilidades y su posible impacto.

Dado que los requisitos de seguridad pueden ser nuevos, tiene la oportunidad de adoptar un enfoque progresivo que aumenta gradualmente los estándares de codificación al estado ideal. Este enfoque proporciona tiempo a los equipos para aprender y automatizar la supervisión y los controles.

Requerir el uso de características, lenguajes y marcos de seguridad probados

Defina y publique una lista de herramientas aprobadas y sus comprobaciones de seguridad asociadas. El uso de soluciones de seguridad bien establecidas y probadas es importante para evitar errores comunes, ya que es muy difícil crear soluciones seguras. Intentar reinventar soluciones de seguridad casi siempre da como resultado un mayor riesgo de seguridad y un desperdicio de tiempo y esfuerzo.

Asegúrese de que las personas con roles de desarrollo e ingeniería aprovechan las nuevas protecciones y funcionalidades de análisis de seguridad. Siempre deben usar el compilador, el enlazador, las bibliotecas y las marcas de compilador y enlazador adecuadas para generar ejecutables seguros.

Las organizaciones deben implementar un proceso de revisión y aprobación para validar la seguridad de los componentes integrados. Deben establecer una directiva para usar solo los componentes aprobados en los procesos de compilación e implementación que se aplican y supervisan.

Seguridad de identidad fundamental

Asegúrese de que el uso y la integración de la identidad siguen los procedimientos recomendados de seguridad bien establecidos. Los actores de amenazas usan técnicas de ataque de identidad con frecuencia contra sistemas de producción y procesos de desarrollo. Un dicho popular dice que "los atacantes no irrumpen, simplemente inician sesión".

La seguridad de identidad tiene dos formas de desarrollarse:

  • Seguridad de identidad para el proceso de desarrollo: asegúrese de que todos los participantes del proceso de desarrollo usan métodos de autenticación seguros para su trabajo diario y solo tienen privilegios necesarios para ejecutar sus tareas de trabajo. Para más información, consulte Control de acceso de identidad/aplicación.
  • Seguridad de identidad para sistemas y aplicaciones: asegúrese de que los sistemas que diseñan y compilan siguen los procedimientos recomendados para los métodos de autenticación y autorización (y no crean sus propias imitaciones débiles de sistemas de identidad probados y mantenidos).

Aplique la seguridad de identidad para sistemas y aplicaciones siguiendo las instrucciones de estos recursos:

Estándares criptográficos

Aplicar prácticas criptográficas sólidas a todo la utilización de criptografía. Siga todas las directrices descritas en la Práctica continua de SDL 4: definir y usar estándares criptográficos.

Para obtener más información sobre el cifrado, consulte el documento técnico Recomendaciones criptográficas de Microsoft SDL.

Protección del entorno de desarrollo

Este control admite la Práctica continua de SDL 6: protección de mi entorno de ingeniería.

Este control se centra en proteger el entorno de desarrollo mediante estaciones de trabajo seguras y entornos de desarrollo integrados (IDE). Este control pone de manifiesto la ventaja de usar un enfoque de Confianza cero en el ciclo de vida de desarrollo de software.

En el panorama actual, los atacantes amplían sus operaciones para dirigirse a las máquinas de las personas con roles de desarrollo y manipulan los procesos de compilación. Un ejemplo fundamental de este ataque fue el experimentado por SolarWinds, donde el atacante insertó una DLL malintencionada antes de las fases finales de la compilación de software. De hecho, esta aplicación afectó enormemente a la aplicación y dio lugar a un ataque dirigido que se distribuyó a miles de clientes en todo el mundo con la cadena de suministro. Para obtener más información sobre el ataque SolarWinds, consulte el blog de Microsoft Análisis de Solorigate, el archivo DLL en peligro que inició un sofisticado ciberataque y cómo Microsoft Defender ayuda a proteger a los clientes.

Es esencial proteger las estaciones de trabajo, crear entornos, identidades y otros sistemas de desarrollo para garantizar la integridad de las aplicaciones desarrolladas. Si no lo hace, se arriesga a que los atacantes pongan en peligro la aplicación a través del sistema de administración de código fuente (SCM) o con la estación de trabajo del desarrollador.

Esta práctica es una base crítica del ciclo de vida de desarrollo y debe establecerse en todos los perfiles.

A lo largo de esta práctica, debe adoptar un enfoque Confianza cero. En su núcleo, el modelo de Confianza cero requiere que cada solicitud de acceso (usuario, servicio o dispositivo) se compruebe como si se origina en una red que no es de confianza, independientemente de dónde se origine la solicitud o a qué recurso accede. Siga la directiva “Autenticar y autorizar siempre” en todos los puntos de datos disponibles. Debe limitar el acceso de los usuarios, especialmente a los usuarios con privilegios, a través de directivas Just-In-Time y Just-Enough-Access (JIT/JEA) y segmentar el acceso para minimizar los posibles daños si se produce una vulneración.

La protección del entorno de desarrollo se puede lograr con varios métodos, pero un buen punto de partida es considerar la estación de trabajo del desarrollador. Mediante el uso de tecnologías como GitHub Codespaces o Microsoft DevBox, se cambia el entorno de desarrollo a las aplicaciones SaaS, que se pueden administrar con la configuración de seguridad y red o a través de directivas organizativas.

Para bloquear aún más las estaciones de trabajo de desarrollador, puede emitir las estaciones de trabajo de acceso con privilegios o estaciones de trabajo de acceso seguro (PAW/SAW). Estas estaciones de trabajo le ayudan a reducir los vectores de amenazas y a garantizar un dispositivo de desarrollador estandarizado y controlado.

Diseño seguro

Realizar el modelo de riesgos (revisión de diseño de seguridad)

Este control admite la Práctica continua de SDL 3: realizar el modelo de riesgos.

Este control identifica las debilidades de seguridad en el diseño que pueden dar lugar a incidentes de seguridad y daños empresariales. Las debilidades de seguridad en el diseño pueden ser difíciles de mitigar después de implementar el diseño, por lo que es fundamental encontrar y corregir estas debilidades al principio del ciclo de vida.

El modelo de riesgos actúa como proceso de revisión de diseño de seguridad, que integra la seguridad en el diseño de un sistema o aplicación.

El modelo de riesgos identifica, evalúa, prioriza y mitiga sistemáticamente los riesgos de seguridad dentro de un sistema de software. Este enfoque estructurado para analizar el diseño y la arquitectura de una aplicación de software identifica posibles amenazas y vulnerabilidades al principio del proceso de desarrollo.

El objetivo final es comprender el sistema y lo que podría ir mal. El modelo de riesgos ayuda a lograr ese objetivo aplicando un conocimiento profundo del propio sistema y de cómo lo ve un atacante potencial.

Normalmente, este proceso adopta la forma de talleres de detección de amenazas en los que un equipo de personas expertas en el sistema y un equipo de personas expertas en seguridad trabajan juntos para detectar y documentar los riesgos. Aunque este proceso puede iniciarse informalmente, debe evolucionar de forma rápida en un proceso estructurado que analice cada aspecto del servicio que se está compilando, cómo se usa e interfaces del sistema.

Las fases del modelo de riesgos son:

  1. Identificar casos de uso, escenarios y recursos: empiece por comprender qué funciones empresariales y casos de uso permite ayudar a evaluar el posible impacto empresarial de cualquier riesgo del sistema e informar a los debates que se deben seguir.
  2. Crear información general sobre la arquitectura: cree un resumen visual de la aplicación (o usa uno existente) para proporcionar una comprensión clara del sistema y cómo funciona. Esta introducción debe incluir: un mapa de procesos empresariales, componentes y subsistemas, límites de confianza, mecanismos de autenticación y autorización, interfaces externas e internas, y flujos de datos entre actores y componentes.
  3. Identificar las amenazas: use una metodología común para enumerar posibles amenazas de seguridad, como el modelo STRIDE o el modelo de riesgo de OWASP.
  4. Identificación y seguimiento de mitigaciones: supervise y realice un seguimiento de los errores de diseño detectados mediante los procesos y herramientas de desarrollo existentes para asegurarse de que las correcciones se implementan y documentan. Este proceso debe incluir la priorización de las mitigaciones que se deben realizar primero para que los equipos dediquen su tiempo primero a los esfuerzos más importantes. Este proceso está controlado por riesgos y es posible que no tenga recursos para mitigar completamente todos los riesgos del primer ciclo. Tenga en cuenta cuidadosamente qué mitigaciones, incluidas las mitigaciones parciales, aumentan el coste de un atacante por el menor coste defensivo y los recursos. El objetivo de la seguridad es provocar un error del atacante. Esto se puede hacer de formas diferentes: se puede bloquear completamente una técnica de ataque, detectarlos para permitir una respuesta de defender, ralentizarlos para dar a los defensores tiempo de respuesta, limitar el ámbito de daño, etc.

Un modelo de riesgo suele servir como un proceso educativo para todos los implicados, así como proporcionar contexto importante para otros planes de seguridad, implementación y pruebas.

Las aplicaciones que incluyen el uso de componentes de inteligencia artificial (IA) deben evaluar los tipos de riesgo específicos asociados a la inteligencia artificial, que son diferentes de las aplicaciones clásicas.

Crear y analizar modelos de riesgos implica comunicarse sobre el diseño de seguridad de sus sistemas, analizar esos diseños en busca de posibles problemas de seguridad mediante una metodología probada y sugerir y administrar mitigaciones para problemas de seguridad.

Código seguro

Análisis de código

Este control admite la Práctica continua de SDL 7: realizar pruebas de seguridad.

Este control se centra en aumentar la seguridad del código a medida que las personas con roles de desarrollo escriben en un entorno de desarrollo integrado (IDE) o a medida que se comprueban en el código. Este control es la piedra angular de las prácticas de DevSecOps, ya que aborda directamente las vulnerabilidades que los atacantes aprovechan con regularidad.

Sin este control, es posible que falten vulnerabilidades que los desarrolladores codifican directamente en la aplicación. Las personas con roles de desarrollo no tienen malas intenciones, pero podrían carecer de las aptitudes necesarias para identificar por qué lo que han codificado no es seguro.

Este control es clave para obtener las ventajas de productividad y seguridad de un enfoque de desplazamiento izquierdo mediante la integración de herramientas directamente en el IDE. Este proceso permite la detección rápida y corrección de vulnerabilidades lo antes y del modo más rentable posible. Este proceso se puede aplicar retroactivamente a las aplicaciones ya desarrolladas mediante la identificación de puntos débiles de seguridad. También se pueden corregir más adelante, aunque con mayor gasto y dificultad.

Este proceso suele tener la forma de complementos IDE o herramientas de examen dedicadas que examinan el código mediante los conjuntos de pruebas de seguridad de aplicaciones estáticas (SAST) y herramientas de pruebas de seguridad de aplicaciones dinámicas (DAST).

Las herramientas de SAST examinan el código base existente y tienen acceso total al código. Las herramientas de SAST pueden identificar las debilidades principales en el propio código. Por otro lado, DAST se ejecuta en la aplicación implementada. Como resultado, no tiene acceso al código y se ejecuta para simular e identificar puntos débiles de seguridad en tiempo de ejecución.

Nota:

Las aplicaciones de IA tienen diferentes tipos de vulnerabilidades (como sesgos y alucinaciones) que las aplicaciones clásicas y requieren herramientas que se centren en ellas.

¡El control de calidad importa! Una consideración clave para ejecutar estas herramientas es asegurarse de que las optimizas para reducir el ruido y el esfuerzo desperdiciado de falsos positivos. La optimización de estas herramientas normalmente requiere un profesional de seguridad con un fondo para desarrolladores que comprenda los procesos de desarrollo de su organización. Los mismos profesionales también pueden proporcionar instrucciones de evaluación de prioridades y conocimientos sobre las detecciones individuales para las personas con roles de desarrollo. Pueden ayudar a distinguir verdaderos y falsos positivos, problemas reales frente a falsas alarmas. Los procesos para que las personas con roles de desarrollo accedan a personas expertas a menudo están estrechamente relacionadas con proporcionar formación de seguridad, como con programas de campeones, equipos de soporte técnico de seguridad de aplicaciones, etc.

Mínimo temporal: asegúrese de habilitar las características de seguridad del IDE integradas e implementar un nivel mínimo de análisis de SAST en el repositorio para identificar vulnerabilidades en toda la aplicación. Debe haber un proceso documentado para corregir los problemas detectados en un tiempo razonable, aunque el estándar de "barra de errores" de los que se deben corregir los errores se limita hasta que la aplicación alcance los perfiles de seguridad estándar equilibrados o altos.

Estándar: asegúrese de examinar completamente todos los componentes con todas las herramientas SAST/DAST aplicables e identificar puntos débiles. Asegúrese de una cobertura de seguridad completa en el código de la aplicación. Asegúrese de seguir el proceso documentado para la corrección y tenga un estándar de "barra de errores" que coincida con la tolerancia al riesgo de su organización.

Alta seguridad: asegúrese de que todas las aplicaciones aplicables aplican un proceso detallado y documentado que aborda todas las vulnerabilidades de seguridad. Aplique correcciones antes de cualquier actividad de compilación o versión. Asegúrase de seguir el proceso documentado para la corrección y tenga una de "barra de errores" que coincida con la tolerancia al riesgo de su organización para cargas de trabajo críticas para la empresa de alta seguridad.

Hay muchas herramientas disponibles que se pueden utilizar para el análisis estático. Revise la lista en Ciclo de vida de desarrollo de seguridad de Microsoft para obtener más información.

Protección de la canalización de CI/CD

Administración de dependencias y cadena de suministro

Este control admite la Práctica continua de SDL 5: proteger la cadena de suministro de software.

Este control se centra en proteger la cadena de suministro de desarrollo mediante herramientas y marcos de análisis de composición de software (SCA), como el marco de consumo seguro de la cadena de suministro (S2C2F). Estos procesos ayudan a reducir el riesgo de poner en peligro el código que no es de Microsoft.

En el panorama actual, la mayoría de las aplicaciones dependen de software de código abierto (OSS) con poca supervisión o control de los consumidores de estos componentes. Este control resalta las estrategias, técnicas y tecnologías principales para ingerir, consumir, usar y mantener el OSS de forma segura. También destaca la protección de las dependencias internas, lo que garantiza un ciclo de vida completo de un extremo a otro, independientemente de quién programó el software.

El error al controlar la cadena de suministro de software le expone a vulnerabilidades significativas introducidas por el código que no controla. Un ejemplo conocido es la vulnerabilidad log4J/Log4Shell, que permitió la ejecución remota de código en cualquier sistema o aplicación mediante este paquete. Estas vulnerabilidades pueden surgir de forma accidental o de forma malintencionada.

La protección de la cadena de suministro es una parte esencial de garantizar un ciclo de vida de desarrollo de seguridad y debe tenerse en cuenta en cada estado de perfil, aunque cada estado debe seguir el mismo proceso estandarizado de ingesta de dependencias.

Mínimo temporal: realiza un inventario de todas las dependencias para comprender el impacto que tiene una vulnerabilidad del OSS en la aplicación. Este inventario se puede lograr mediante Dependabot u otras herramientas de Análisis de composición de software (SCA). Estas herramientas también pueden ayudarle a generar una lista de materiales de software (SBOM).

Estándar: analice todas las vulnerabilidades del OSS y corrija automáticamente con solicitudes de incorporación de cambios automáticas. Este control también se puede lograr mediante Dependabot y el gráfico o revisión de dependencias de GitHub.

Alta seguridad: bloquee activamente todos los paquetes no seguros con vulnerabilidades de seguridad que se usan en la aplicación.

Para obtener más información sobre este control y medir la madurez de la seguridad del sistema operativo, revise los Marcos de la cadena de suministro del OSS y la documentación de procedimientos recomendados de GitHub sobre Cómo proteger el ciclo de vida de desarrollo.

Revisión del código de seguridad

Este control se centra en tener un código de revisión de expertos en seguridad para identificar posibles errores de seguridad. Esto ayuda a encontrar problemas de seguridad difíciles en los que es difícil automatizar la detección.

Esta revisión podría realizarse por: un elemento del mismo nivel en el mismo equipo con experiencia en seguridad de aplicaciones, una persona experta en seguridad dentro de la organización, una persona experta en seguridad de aplicaciones del equipo central de seguridad de aplicaciones o un tercero externo.

Esta revisión siempre debe ser una persona independiente de la persona con roles de desarrollo que escribió el código. Esta revisión debe realizarse como una actividad independiente una vez completado el análisis de código automatizado.

Mínimo temporal: este control se recomienda para este perfil.

Estándar: este control se recomienda para este perfil.

Alta seguridad: este control es necesario para todas las aplicaciones de alta seguridad y a menudo implica a varias personas expertas individuales.

Examen de credenciales y secretos

Este control admite la Práctica continua de SDL 7: realizar pruebas de seguridad.

Este control se centra en reducir el riesgo de las claves de autenticación y otros secretos expuestos en el código. Los actores de amenazas tienen los conocimientos y automatización necesaria para buscar y aprovechar secretos incrustados en el código.

El mejor enfoque es usar identidades administradas y protocolos de autenticación modernos en lugar de claves y secretos siempre que sea posible. Aunque el uso de claves y secretos de API ha sido tradicionalmente una práctica de codificación y pruebas, el método preferido siempre debe ser la autenticación basada en identidades en los recursos debido a las mayores capacidades de seguridad y administración del ciclo de vida. La implementación de este control tiene la forma de usar identidades administradas, como identidades administradas para recursos de Azure.

Si se requiere el uso de secretos, debe protegerlos con todo su ciclo de vida, incluida su creación, uso, rotación regular y revocación. Evite usar directamente secretos en el código y almacenarlos solo en un sistema de almacenamiento seguro de claves o secretos, como Azure Key Vault o un módulo de seguridad de hardware (HSM) si es necesario. En ningún caso, se almacenan las claves de texto sin formato y los secretos en el código, ni de forma temporal. Los atacantes encontrarán y aprovecharán estos secretos.

Importante

Los repositorios de código fuente internos no son seguros.

Los repositorios internos deben estar sujetos a los mismos requisitos que los repositorios orientados públicamente, ya que los actores de amenazas suelen buscar secretos y claves en repositorios después de obtener acceso a un entorno con la suplantación de identidad (phishing) u otros medios. Esto es necesario para un enfoque de Confianza cero que supone controles de seguridad de vulneración y diseños en consecuencia.

Estándar: la buena higiene secreta es esencial y se requiere en todos los perfiles.

Nota:

A medida que los equipos o atacantes encuentran estos secretos, debe asegurarse de que la clave no se puede usar para acceder a los recursos (varía según el tipo de recurso) además de modificar el mecanismo a un método de acceso más seguro, como las identidades administradas.

Entre los detalles y los recursos se incluyen:

Nota:

Se recomienda encarecidamente usar claves por carga de trabajo con soluciones de almacenamiento secreto como Azure Key Vault.

Protección de las canalizaciones

Este control admite la Práctica continua de SDL 5: proteger la cadena de suministro de software.

Este control se centra en proteger la canalización de DevOps y todos los artefactos creados durante los procesos de compilación de la aplicación.

Las canalizaciones son una parte esencial de la automatización de las actividades repetibles principales dentro del ciclo de vida de DevSecOps. En CI/CD, el equipo combina el código de desarrollo en un código base central según una programación periódica y, después, ejecuta automáticamente procesos de compilación y prueba estándar, incluidos los conjuntos de herramientas de seguridad.

El uso de canalizaciones para ejecutar scripts o implementar código en entornos de producción puede presentar desafíos de seguridad únicos. Asegúrese de que las canalizaciones de CI/CD no se conviertan en vías para ejecutar código malintencionado, permitir que se roben las credenciales o proporcionar a los atacantes cualquier área expuesta para el acceso. También debe asegurarse de que solo se implemente el código que su equipo pretende publicar. Este proceso incluye artefactos de las canalizaciones de CI/CD, especialmente artefactos que se comparten entre diferentes tareas que se pueden usar como parte de un ataque.

La generación de la lista de materiales de software (SBOM) debe automatizarse en el proceso de compilación para crear este artefacto de origen de código críticamente importante sin necesidad de acciones manuales de personas con roles de desarrollo.

La seguridad de la canalización se puede garantizar al asegurar un buen control de acceso a los recursos usados en la canalización, y validando o actualizando las dependencias principales o los scripts con regularidad. Es importante tener en cuenta que los scripts usados en las canalizaciones de CI/CD también son código y deben tratarse de la misma manera que trata el resto del código del proyecto.

Nota:

La seguridad de la canalización depende de la seguridad de la infraestructura subyacente, y de las cuentas o identidades que se usan para el proceso. Para obtener más información, consulte la protección del entorno de desarrollo y los controles de operaciones seguras (controles de identidad/acceso a aplicaciones, controles de host/contenedor, controles de acceso a la red).

Estándar: este control se debe evaluar en un nivel de acceso a todos los recursos del proyecto; es un control necesario en todos los niveles de perfil de DevSecOps.

Para más información sobre la seguridad de canalización, consulte Protección de Azure Pipelines.

Operaciones seguras

Pruebas de penetración de sitios en directo

Este control admite la Práctica continua de SDL 7: realizar pruebas de seguridad.

Hacer que los evaluadores profesionales de penetración de aplicaciones intenten poner en peligro una instancia activa de la carga de trabajo completa. Esta prueba comprueba que los controles de seguridad de la carga de trabajo sean eficaces y coherentes. Las pruebas de penetración ayudan a encontrar y resaltar la ruta menos resistente que un atacante podría usar para aprovechar la aplicación y poner en peligro la empresa. Las pruebas de penetración pueden ser increíblemente valiosas cuando se realizan en el momento adecuado. Úselas una vez que haya mitigado las vulnerabilidades de seguridad baratas y fáciles de aprovechar en exámenes anteriores.

Se recomienda realizar esta prueba en todos los niveles de los perfiles de seguridad de DevSecOps.

Mínimo temporal: se recomienda realizar una prueba de penetración en todas las aplicaciones. Debido a restricciones de tiempo, es posible que solo pueda identificar métodos más fáciles en la aplicación que un atacante podría aprovechar. Planee llevar esto rápidamente al nivel estándar como mínimo.

Estándar: en un perfil estándar, se recomienda realizar una prueba de penetración. En este caso, es posible que descubra vulnerabilidades más complejas debido a la atención adicional que se toma al principio del proceso de desarrollo.

Alta seguridad: para las aplicaciones empresariales de línea y las cargas de trabajo críticas, es un requisito completar una prueba de penetración. Cualquier vulnerabilidad de estas aplicaciones debe tratarse con más atención y cuidado.

Integre los resultados y comentarios de estas actividades para mejorar los procesos y herramientas de seguridad.

Controles de acceso de identidad o aplicación

Este control admite la Práctica continua de SDL 8: garantizar la seguridad de la plataforma operativa y la Práctica 6: proteger el entorno de ingeniería.

Asegúrese de que se siguen los procedimientos recomendados de seguridad para la administración de identidades y acceso, incluida la protección del acceso con privilegios, todos los elementos técnicos del entorno de desarrollo, la canalización de CI/CD, la carga de trabajo operativa y otros sistemas de desarrollo. Los actores de amenazas tienen métodos y automatización sofisticados para ataques de identidad que usan con frecuencia en sistemas de producción y procesos de desarrollo. La administración de identidades y acceso es un pilar fundamental del modelo de Confianza cero que Microsoft recomienda.

Asegúrese de que se siguen los procedimientos recomendados de seguridad para todos los sistemas de desarrollo y la infraestructura que los hospeda (máquinas virtuales, contenedores, dispositivos de red, etc.).

Mínimo temporal: asegúrese de que todos usan la autenticación multifactor y solo pueden acceder a los sistemas necesarios para realizar sus tareas diarias.

Estándar: asegúrese de que los componentes de la infraestructura que hospedan la carga de trabajo (como máquinas virtuales, contenedores, red y sistemas de identidad) cumplen los procedimientos recomendados de seguridad para la administración de identidades y acceso, incluida la protección del acceso con privilegios.

Alta seguridad: implemente una estrategia de Confianza cero completa que incorpore MFA, detección y respuesta de amenazas de identidad y administración de derechos de infraestructura en la nube (CIEM). Realice un modelo de riesgos específico de la carga de trabajo de los sistemas de identidades y los componentes que admiten cada carga de trabajo de alta seguridad.

Las identidades administradas son el método de autenticación más seguro y preferido siempre que sea posible. El uso de tokens y secretos es menos seguro debido a la necesidad de almacenarlos y recuperarlos en el nivel de aplicación. Además, las identidades administradas se revierten automáticamente sin necesidad de intervención manual.

Entre los detalles y los recursos se incluyen:

Controles de host, contenedor y entorno

Este control admite la Práctica continua de SDL 8: garantizar la seguridad de la plataforma operativa y la Práctica 6: proteger el entorno de ingeniería.

Asegúrese de que se siguen los procedimientos recomendados de seguridad para todos los recursos de proceso y entornos de hospedaje para todos los elementos técnicos del ciclo de vida de desarrollo. Los actores de amenazas tienen métodos y automatización sofisticados para ataques a la infraestructura y al punto de conexión de los usuarios que usan con frecuencia en sistemas de producción y procesos de desarrollo. La seguridad de infraestructura es un pilar fundamental del modelo de Confianza cero que Microsoft recomienda.

Este control debe incluir todos los elementos del ciclo de vida operativo y de desarrollo, entre los que se incluyen, entre otros:

  • Entornos y estaciones de trabajo generales de TI/operativos.
  • Estaciones de trabajo y entornos de desarrollo dedicados.
  • Infraestructura de canalización de CI/CD.
  • Entorno del host de la carga de trabajo.
  • Cualquier otro sistema de desarrollo.

Este control incluye cualquier recurso que pueda ejecutar cualquier código, entre los que se incluyen, entre otros:

  • Hosts de máquina virtual (VM) y máquinas virtuales.
  • Contenedores e infraestructura de contenedor.
  • Plataformas de hospedaje de aplicaciones, scripts y código.
  • Suscripciones o cuentas en la nube e inscripciones.
  • Estaciones de trabajo de Administración de TI, usuario y desarrollador.

Asegúrese de aplicar el procedimiento recomendado de seguridad a los componentes de infraestructura, incluidas las actualizaciones de seguridad (revisiones), las configuraciones de seguridad de línea de base, etc.

Mínimo temporal: aplique configuraciones empresariales estándar para hosts y suscripciones.

Estándar: asegúrese de que la infraestructura cumple los procedimientos recomendados de seguridad descritos en Microsoft Cloud Security Benchmark (MCSB).

Alta seguridad: aplique estrictamente los estándares MCSB y realice un modelo de riesgos específico de la carga de trabajo de infraestructura que admita cada carga de trabajo de alta seguridad.

Entre los detalles y los recursos se incluyen:

Controles de acceso a la red

Este control admite la Práctica continua de SDL 8: garantizar la seguridad de la plataforma operativa y la Práctica 6: proteger el entorno de ingeniería.

Asegúrese de que se siguen los procedimientos recomendados de seguridad para la administración del acceso a la red para todos los elementos técnicos del entorno de desarrollo, la canalización de CI/CD, el entorno de carga de trabajo operativo y otros sistemas de desarrollo. Los actores de amenazas tienen métodos y automatización sofisticados para ataques de identidad que usan con frecuencia en sistemas de producción y procesos de desarrollo. La seguridad de red es un pilar fundamental del modelo de Confianza cero que Microsoft recomienda.

La seguridad de red debe incluir:

  • Protección de red externa: aislamiento del tráfico externo o de Internet no solicitado y mitigación de tipos de ataque conocidos. Este aislamiento suele tener la forma de servidor de seguridad de Internet, Web Application Firewall (WAF) y soluciones de seguridad de API.
  • Protección de red interna: aislamiento del tráfico interno no solicitado (desde otras ubicaciones de red empresarial). Este aislamiento puede usar controles similares como protección de red externa y puede ser granular a la carga de trabajo o a componentes individuales y direcciones IP específicos.
  • Mitigaciones de denegación de servicio: protecciones contra denegación de servicio distribuido (DDoS) y otros ataques por denegación de servicio.
  • Security Service Edge (SSE): uso de microsegmentación del lado cliente para proporcionar acceso seguro directamente a los recursos, incluida la aplicación de directivas de Confianza cero.

Asegúrese de que se siguen los procedimientos recomendados de seguridad para todos los sistemas de desarrollo y la infraestructura que los hospeda (máquinas virtuales, contenedores, dispositivos de red, etc.).

Mínimo temporal: aplique configuraciones empresariales estándar para la carga de trabajo.

Estándar: asegúrese de que todos los sistemas tienen protección de red externa, protección contra DDoS y una protección de red interna por carga de trabajo como mínimo.

Alta seguridad: todas las protecciones estándar más la granularidad alta de las protecciones de red internas, la tunelización forzada del tráfico de servidor saliente con mecanismos de protección de red externos y un modelo de riesgos específico de la carga de trabajo de la infraestructura de red que admite cada carga de trabajo de alta seguridad.

Entre los detalles y los recursos se incluyen:

Supervisión, respuesta y recuperación

Este control admite la Práctica continua de SDL 9: implementar la supervisión y la respuesta de seguridad.

Asegúrese de que los equipos de operaciones de seguridad (SecOps/SOC) tengan procedimientos de visibilidad, detección de amenazas y respuesta para cargas de trabajo (API y aplicaciones), así como la infraestructura que los hospeda. Asegúrese de que los procesos entre equipos y herramientas entre SecOps y los equipos de infraestructura/carga de trabajo permiten una recuperación rápida después de un ataque.

Este control mantiene la seguridad de la carga de trabajo una vez que está en producción y se ejecuta activamente en su organización. Este proceso debe integrarse con la funcionalidad de operaciones de seguridad existentes que detecte y responda a incidentes de seguridad.

La supervisión de seguridad para cargas de trabajo personalizadas combina soluciones de detección y respuesta extendidas (XDR) para componentes comunes mediante el análisis de registros y otros datos de la aplicación para detectar e investigar posibles amenazas de seguridad. Los datos de aplicación personalizados suelen incluir: información sobre las solicitudes de usuario, la actividad de la aplicación, los códigos de error, el tráfico de red, otros detalles relevantes de la aplicación, las bases de datos, los puntos de conexión de red y otros componentes del sistema.

A continuación, estos datos se mejoran con información de inteligencia contra amenazas en tiempo real para identificar patrones de comportamiento anómalo que podrían indicar posibles intentos de infiltrarse en la red. Una vez agregadas, correlacionadas y normalizadas, la plataforma XDR y la Administración de eventos e información de seguridad (SIEM) ofrece acciones de corrección.

Mínimo temporal: implemente funcionalidades de XDR en su entorno para supervisar el tráfico de los dispositivos de usuario final.

Estándar: implemente XDR y detecciones de SIEM personalizadas que identifiquen el comportamiento anómalo en relación con el entorno general. Este perfil puede incluir detecciones personalizadas para cargas de trabajo individuales.

Alta seguridad: controles estándar más detecciones personalizadas por carga de trabajo basadas en información sobre el modelo de riesgos de la carga de trabajo. Combine este perfil con IA para proporcionar reconocimiento contextual a las recomendaciones de corrección.

Pasos siguientes

Adopte estos controles de seguridad y adáptelos a los requisitos de tolerancia a riesgos y productividad de su organización. Debe usar un enfoque de mejora continua en el que se crea continuamente hacia el estado ideal.

Empiece por priorizar los controles y los niveles de destino mínimos ideales. Asegúrese de que tiene un impacto positivo en la seguridad y cambios de baja fricción en primer lugar. Priorice, implemente e integre el primer control y repita el proceso con el siguiente control.

Primero, debe priorizar las bases críticas debido a su amplio impacto positivo y análisis de credenciales y secretos debido a su alto impacto y uso frecuente del atacante.