Estrategias de arquitectura para pruebas de seguridad

Se aplica a esta recomendación de lista de comprobación de seguridad de Azure Well-Architected Framework:

Las pruebas rigurosas son la base del buen diseño de seguridad. Las pruebas también son una manera proactiva de detectar vulnerabilidades en el sistema.

Establecer el rigor de las pruebas a través de la cadencia y la comprobación desde varias perspectivas. Incluya perspectivas de dentro hacia fuera que prueben la plataforma y la infraestructura, y evaluaciones de fuera hacia dentro que prueben el sistema como lo haría un atacante externo.

Las estrategias clave de este artículo se basan en las prácticas de prueba fundamentales descritas en Estrategias de arquitectura de OE:09 para pruebas. Revise primero ese artículo. En esta guía se proporcionan recomendaciones para probar la posición de seguridad de la carga de trabajo. Implemente estos métodos de prueba para mejorar la resistencia de la carga de trabajo a los ataques y mantener la confidencialidad, la integridad y la disponibilidad de los recursos.

Terminología

Colaboración con expertos en seguridad para diseñar pruebas

Participe en la planificación de pruebas. A menudo, una organización centraliza esta tarea. Asegúrese de que el equipo participa en ese proceso de diseño para que las garantías de seguridad se alineen con la funcionalidad de la aplicación.

Adopte una mentalidad de dar por hecha una brecha de seguridad. Diseñe los casos de prueba con la suposición de que el sistema está bajo ataque y el atacante está trabajando dentro del entorno. Simule las pruebas para reflejar escenarios de ataque realistas, como la validación de la contención del movimiento lateral dentro de una máquina virtual de aplicación en peligro. De este modo, puede descubrir posibles vulnerabilidades y priorizar las pruebas en consecuencia.

Comparta los diagramas arquitectónicos, el modelo de amenazas y otra documentación pertinente para probar la carga de trabajo de forma significativa.

Priorizar las pruebas basadas en el modelado de amenazas y los flujos críticos

El modelado de amenazas es una práctica clave para identificar posibles amenazas y vulnerabilidades en la carga de trabajo. Use las clasificaciones de gravedad del modelo de amenazas para priorizar y definir el ámbito de los esfuerzos de prueba. Las amenazas de gravedad más altas contra los flujos más críticos merecen la mayor cobertura.

Abarque toda la superficie de ataque de la carga de trabajo. Evalúe la identidad, el código de aplicación, los controles de infraestructura, los componentes de terceros, las bibliotecas y los servicios, y los procesos automatizados y humanos, como los flujos de trabajo de aprobación y las revisiones de acceso.

Comience con los controles de identidad y acceso porque una identidad en peligro omite la mayoría de las defensas de bajada. A continuación, valide los límites de red y, por último, las defensas de nivel de aplicación.

Dé prioridad a los flujos que controlan la autenticación, los datos confidenciales o las transacciones financieras. Para cada flujo crítico, identifique las amenazas con la clasificación de gravedad más alta en el modelo de amenazas. Cree casos de prueba controlados por riesgos que asignen cada amenaza al control destinado a mitigarlo.

Un buen ejercicio de modelado de amenazas apunta a áreas clave para la cobertura y la frecuencia de las pruebas. Para obtener recomendaciones sobre el modelado de amenazas, consulte Recomendaciones para proteger un ciclo de vida de desarrollo.

Riesgo: los modelos de amenazas obsoletos pueden provocar esfuerzos de prueba mal alineados. Actualice periódicamente el modelo de amenazas para reflejar los cambios en la carga de trabajo y el panorama de amenazas en constante evolución.

Aprovechar la experiencia de terceros

Los equipos internos pueden tener puntos ciegos. Los expertos externos y los investigadores colaborativos ven su entorno de trabajo como lo ve un atacante. Incorpore expertos especializados para probar la carga de trabajo desde la perspectiva de un adversario y proporcionar información sobre las últimas técnicas y tendencias de ataque.

Evite otorgar un acceso demasiado permisivo a su carga de trabajo. Proporcione a los evaluadores externos solo el acceso que requiere su participación específica. Una prueba de penetración de caja negra no necesita código ni acceso interno, mientras que una revisión de caja blanca necesita código fuente, documentos de diseño o registros.

Evalúe si el equipo tiene la capacidad de evaluar los informes externos antes de iniciar un programa. A continuación, establezca un programa de recompensas de errores o un mecanismo para que la comunidad notifique problemas de seguridad. Evalúe cada hallazgo notificado, reincorpore las vulnerabilidades confirmadas a su modelo de amenazas y añada un caso de prueba para detectar cualquier regresión.

Prueba de controles de cumplimiento y generación de pruebas preparadas para auditoría

El cumplimiento no es una revisión única. Trate cada control normativo como requisito probable para que siempre tenga pruebas nuevas para los auditores.

Identifique las regulaciones que debe cumplir la carga de trabajo. Asigne cada control normativo a un caso de prueba específico. Programe las pruebas para que se ejecuten con una cadencia periódica y antes de cada puesta en marcha. Almacene la salida de prueba en una ubicación auditable para que pueda generar evidencias a petición.

Contrapartida: Las pruebas de controles regulatorios pueden ralentizar las operaciones. Por ejemplo, las pruebas previas al despliegue añaden latencia al pipeline. También hay un costo adicional de ejecutar esas operaciones. Priorice las pruebas para los controles con el mayor impacto en la auditoría y el riesgo.

Riesgo: la evidencia de auditoría es confidencial. Sin protección de integridad y registro de acceso, el almacén de evidencias se convierte en un destino de ataque y en una posible infracción de cumplimiento.

Protección de recursos de prueba

Los recursos de prueba son en sí mismos una superficie expuesta a ataques. Proteja su confidencialidad, integridad y disponibilidad para que las pruebas no expongan información confidencial ni abran nuevos vectores de ataque.

• Use datos sintéticos o saneados que no contengan información de identificación personal (PII) ni datos de producción.
• Conserve los datos de prueba solo siempre que sea necesario y elimínelo de forma segura.
• Confirme que las reglas de residencia de datos transfronterizas se aplican en entornos de prueba que abarcan regiones.
• Genere credenciales de prueba dedicadas, claves de API y certificados. Almacénelos en una instancia independiente del almacén de claves con sus propias directivas de acceso.
• Configure entornos de prueba aislados que reflejen controles de seguridad de producción, como grupos de seguridad de red (NSG), directivas de control de acceso basado en rol (RBAC), firewall y reglas de prevención de pérdida de datos (DLP). Aplique la misma guía de segmentación que la producción. Para obtener más información, consulte Recomendaciones para la estrategia de segmentación.

Realizar exámenes de vulnerabilidades regulares en los recursos de prueba

Examine los recursos de prueba para detectar vulnerabilidades en la misma cadencia que los recursos de producción, incluido el código de prueba, la infraestructura como el código (IaC), las imágenes de contenedor y máquina virtual, los repositorios y las canalizaciones. Use herramientas que se integren con los flujos de trabajo de desarrollo e implementación para automatizar estas comprobaciones.

Establecer un ritmo continuo de pruebas para la carga de trabajo

Trate las pruebas de seguridad como una actividad continua que mantiene la posición de seguridad de la carga de trabajo actual a medida que evolucionan las amenazas, el código y las configuraciones. Ejecute pruebas según una programación para que los cambios no introduzcan riesgos de seguridad ni regresiones. Prepárese para las validaciones de seguridad de la organización que pueden producirse en cualquier momento y para las pruebas desencadenadas por un incidente de seguridad. Las siguientes secciones describen las cadencias que deben tenerse en cuenta en la planificación.

Pruebas rutinarias

Las pruebas rutinarias establecen la línea base para la posición de seguridad de la carga de trabajo. Llevarlas a cabo con una cadencia regular, como parte de los procedimientos operativos estándar y para cumplir los requisitos de cumplimiento. Puede ejecutar varias pruebas con diferentes cadencias, pero la clave es que las lleve a cabo periódicamente y según una programación.

Diversifique el conjunto de pruebas para comprobar las garantías de identidad, almacenamiento y transmisión de datos y canales de comunicación. A medida que descubra nuevos problemas en los mismos puntos del ciclo de vida, agregue nuevos casos de prueba.

No solo confíe en pruebas automatizadas. Use pruebas manuales para encontrar vulnerabilidades que solo pueden detectar los conocimientos humanos y para el trabajo exploratorio sobre riesgos desconocidos.

Pruebas improvisadas

Las pruebas improvisadas proporcionan validación a un momento dado de las defensas de seguridad. Alertas de seguridad que pueden afectar a la carga de trabajo en ese momento desencadenan estas pruebas. Los mandatos de la organización pueden requerir una mentalidad de pausa y prueba para comprobar la eficacia de las estrategias de defensa si la alerta se escala a una emergencia.

La ventaja de las pruebas improvisadas es la preparación de un incidente real. Estas pruebas pueden ser una función que obliga a realizar pruebas de aceptación de usuario (UAT).

El equipo de seguridad puede auditar todas las cargas de trabajo y ejecutar estas pruebas según sea necesario. Como propietario de la carga de trabajo, debe facilitar y colaborar con los equipos de seguridad. Negocia un plazo suficiente con los equipos de seguridad para que puedas prepararte. Confirme y comunique a su equipo y a las partes interesadas que estas interrupciones son necesarias.

En otros casos, es posible que tenga que ejecutar pruebas e informar del estado de seguridad del sistema contra la amenaza potencial.

Contrapartida: Dado que las pruebas improvisadas son sucesos perturbadores, es de esperar que tengas que repriorizar tareas, lo que podría retrasar otros trabajos planificados.

Riesgo: Existe el riesgo de lo desconocido. Las pruebas improvisadas pueden ser esfuerzos únicos sin procesos o herramientas establecidos. Pero el riesgo predominante es la posible interrupción del ritmo de negocio. Evalúe esos riesgos en relación con las ventajas.

Pruebas de incidentes de seguridad

Use pruebas que detecten la causa de un incidente de seguridad en su origen. Resuelva estas brechas de seguridad para evitar que el incidente se repita.

Los incidentes también mejoran los casos de prueba a lo largo del tiempo al descubrir brechas existentes. El equipo debe aplicar las lecciones aprendidas del incidente e incorporar de forma rutinaria mejoras.

Validación de controles de seguridad en toda la superficie expuesta a ataques

Use una variedad de metodologías de prueba para obtener una cobertura completa y descubrir brechas en los controles de seguridad, las configuraciones incorrectas y las debilidades en la observabilidad y la detección. La mayoría de las pruebas descritas en esta sección se pueden ejecutar como pruebas rutinarias. Sin embargo, la repetibilidad puede incurrir en costos y provocar interrupciones. Tenga en cuenta esos inconvenientes cuidadosamente.

Pruebe los controles de cifrado. Los errores de cifrado son silenciosos. Los datos se protegen hasta que se revela una vulneración de seguridad.

• Verifique que el cifrado se aplica, no solo que está configurado.
• Vuelva a probar después de cada cambio de clave, renovación de certificados e infraestructura.

Pruebe los controles de red. Los límites de red son donde se aplica la segmentación.

• Pruóbelos después de que cambie cualquier topología de red.
• Compruebe que se aplican las reglas de denegación por defecto y que las rutas de tráfico permitidas coinciden con lo previsto en su arquitectura.

Pruebe el código de la aplicación. Las defensas de capa de aplicación son el último límite antes de que un atacante alcance los datos.

• Valide que las aplicaciones implementadas resistan patrones de ataque comunes en lugar de examinar solo el código fuente en tiempo de compilación.
• Ejecute técnicas de pruebas de seguridad de aplicaciones (AST) en el código fuente para confirmar prácticas de codificación seguras y detectar errores en tiempo de ejecución, como daños en la memoria y problemas de privilegios. Para obtener más información, consulte Vínculos de la comunidad.

Simular ataques basados en identidades y comprobar la detección

Los ataques basados en identidades son el vector de ataque inicial más común. Simulación de estos ataques para validar que los controles de identidad funcionan y que la supervisión captura los eventos.

Los controles de acceso son la primera línea de defensa. Pruóbelos después de cada cambio de rol o directiva y en una programación automatizada. Simule patrones de ataque comunes y confirme que los controles aplican privilegios mínimos y resisten los intentos de omisión.

Tenga en cuenta estos patrones de ataque al diseñar pruebas:

• Omisión de autorización
• Robo y reproducción de tokens
• Desplazamiento lateral entre cuentas o servicios
• Escalación de privilegios

Valide ambos lados de cada control:

• Casos positivos: los usuarios autorizados tienen éxito.
• Casos negativos: los intentos no autorizados se bloquean y registran.

Probar la detección de amenazas y las alertas

La detección que no desencadena una alerta proporciona poco valor. Pruebe la supervisión y las alertas como parte de cada validación de control de seguridad y compruebe que los mecanismos diseñados para detectar ataques funcionan según lo previsto.

Ejecute simulaciones de un extremo a otro de los ataques y confirme cada fase de la canalización de detección:

• Valide que los eventos de seguridad, como los intentos de inicio de sesión, los cambios de permisos y las operaciones de token se registran con suficiente detalle.
• Compruebe que la plataforma de administración de eventos e información de seguridad (SIEM) o el panel de operaciones de seguridad correlacionan los eventos relacionados.
• Establezca un acuerdo de nivel de servicio (SLA) para las alertas y compruebe que las alertas permitan actuar y se muestren dentro de ese plazo.
• Compruebe que las cuentas no administrativas no pueden alterar ni eliminar los registros.
• Confirme que se activa el mecanismo de detección para cada ataque simulado. Por ejemplo, si simula un ataque de denegación de servicio distribuido (DDoS) con patrones de tráfico válidos, confirme que la limitación de velocidad detecta y la mitiga.

Para cargas de trabajo maduras, validar los mecanismos de control de gobernanza mediante pruebas rutinarias. Introduzca intencionadamente configuraciones no seguras y compruebe que la canalización detecta y responde. Confirme que Azure Policy o restricciones de zona de aterrizaje aplican las protecciones esperadas. Normalmente, la plataforma o el equipo de seguridad realizan estas pruebas, no el equipo de carga de trabajo.

Reforzar las defensas con pruebas basadas en adversarios

Use pruebas que permitan la búsqueda de amenazas mediante la simulación de ataques reales. Estas pruebas pueden identificar posibles actores de amenazas, sus técnicas y sus vulnerabilidades de seguridad que suponen una amenaza para la carga de trabajo. Haz que los ataques sean lo más realistas posible. Use todos los vectores de amenazas potenciales que identifique durante el modelado de amenazas.

Estas son algunas ventajas de las pruebas a través de ataques reales:

• Al hacer que estos ataques formen parte de las pruebas rutinarias, use una perspectiva externa para comprobar la carga de trabajo y asegurarse de que la defensa pueda resistir un ataque.
• En función de las lecciones que aprenden, el equipo actualiza sus conocimientos y nivel de aptitud. El equipo mejora la conciencia situacional y puede evaluar automáticamente su preparación para responder a incidentes.

Riesgo: las pruebas en general pueden afectar al rendimiento. Las pruebas destructivas pueden eliminar o dañar los datos y causar problemas de continuidad empresarial. También hay riesgos asociados a la exposición de la información. Mantener la confidencialidad de los datos. Asegúrese de la integridad de los datos después de completar las pruebas.

Algunos ejemplos de pruebas simuladas incluyen pruebas de caja negra y de caja blanca, pruebas de penetración y ejercicios de juego de guerra.

Pruebas de caja negra y de caja blanca

Estos tipos de prueba ofrecen dos perspectivas diferentes. En las pruebas de caja negra, los elementos internos del sistema no están visibles. En las pruebas de caja blanca, el evaluador tiene una buena comprensión de la aplicación e incluso tiene acceso al código, los registros, la topología de recursos y las configuraciones para realizar el experimento.

Riesgo: la diferencia entre los dos tipos es el costo inicial. Las pruebas de caja blanca pueden ser costosas en términos de tiempo necesario para comprender el sistema. En algunos casos, las pruebas de caja blanca requieren la compra de herramientas especializadas. Las pruebas de caja negra no necesitan tiempo de preparación, pero podría no ser tan eficaz. Es posible que tenga que hacer un esfuerzo adicional para descubrir problemas. Es un compromiso de inversión de tiempo.

Pruebas que simulan ataques mediante pruebas de penetración

Los expertos en seguridad que no forman parte de los equipos de TI o aplicación de la organización llevan a cabo pruebas de penetración o pruebas de pentesting. Miran el sistema de la misma manera en que los actores malintencionados analizan una superficie de ataque. Su objetivo es encontrar brechas de seguridad mediante la recopilación de información, el análisis de vulnerabilidades y la generación de informes de los resultados.

Compromiso: Las pruebas de penetración son improvisadas y pueden ser costosas en términos de interrupciones y inversión monetaria, ya que las pruebas de penetración suelen ser ofrecidas por profesionales externos como un servicio pago.

Riesgo: un ejercicio de prueba de penetración podría afectar al entorno de ejecución y podría disrumpir la disponibilidad para el tráfico normal.

Es posible que los profesionales necesiten acceso a datos confidenciales en toda la organización. Siga las reglas de compromiso para asegurarse de que el acceso no se utilice de manera incorrecta. Consulte los recursos enumerados en Vínculos relacionados.

Pruebas que simulan ataques a través de ejercicios de juego de guerra

En esta metodología de ataques simulados, dos equipos participan:

• El equipo rojo actúa como adversario e intenta modelar ataques reales. Si tienen éxito, encontrará huecos en el diseño de seguridad y evaluará la contención del radio de explosión de sus infracciones.

• El equipo azul es el grupo de trabajo que defiende contra los ataques. Prueban su capacidad de detectar, responder y corregir los ataques. Validan las defensas que protegen los recursos de carga de trabajo.

Si realizas estas pruebas de forma rutinaria, los ejercicios del juego de guerra pueden proporcionar visibilidad y garantías continuas de que tus defensas funcionan según lo diseñado. Los ejercicios de simulación pueden potencialmente evaluar diferentes niveles dentro de las cargas de trabajo.

Una opción popular para simular escenarios de ataque realistas es el entrenamiento de simulación de ataques de Microsoft Defender para Office 365.

Para obtener más información, consulte Información e informes para el entrenamiento de simulación de ataques.

Para obtener información sobre la configuración del equipo rojo y el equipo azul, consulte Microsoft Cloud Red Teaming.

Facilitación de Azure

Microsoft Sentinel es un control nativo que combina la administración de eventos de información de seguridad (SIEM) y las funcionalidades de respuesta automatizada de orquestación de seguridad (SOAR). Analiza eventos y bitácoras de varias fuentes conectadas. En función de los orígenes de datos y sus alertas, Microsoft Sentinel crea incidentes y realiza el análisis de amenazas para la detección temprana. A través de análisis y consultas inteligentes, puede buscar de forma proactiva problemas de seguridad. Si hay un incidente, puede automatizar los flujos de trabajo. Además, mediante el uso de plantillas de libro, puede obtener rápidamente información a través de la visualización.

Para obtener documentación del producto, consulte Funcionalidades de búsqueda en Microsoft Sentinel.

Microsoft Defender para la nube ofrece un examen de vulnerabilidades para diversas áreas tecnológicas. Para obtener más información, consulte Habilitación del examen de vulnerabilidades con administración de vulnerabilidades de Microsoft Defender: Microsoft Defender para la nube.

La práctica de DevSecOps integra pruebas de seguridad como parte de una mentalidad de mejora continua y continua. Los ejercicios de juego de guerra son una práctica común que se integra en el ritmo de negocio en Microsoft. Para obtener más información, consulte Seguridad en DevOps (DevSecOps).

Azure DevOps admite herramientas de terceros que puede automatizar como parte de las canalizaciones de integración continua o implementación continua. Para más información, consulte Habilitación de DevSecOps con Azure y GitHub: Azure DevOps.

Vínculos relacionados

Siga las normas de participación para asegurarse de que el acceso no se utilice de manera indebida. Para obtener instrucciones sobre cómo planear y ejecutar ataques simulados, consulte los siguientes artículos:

• Reglas de compromiso para pruebas de penetración

• Pruebas de penetración

Puede simular ataques de denegación de servicio (DoS) en Azure. Asegúrese de seguir las directivas establecidas en las pruebas de simulación de Azure DDoS Protection.

Vínculos de la comunidad

Pruebas de seguridad de aplicaciones: herramientas, tipos y procedimientos recomendados: recursos de GitHub describe los tipos de metodologías de prueba que pueden probar las defensas en tiempo de compilación y tiempo de ejecución de la aplicación.

El Estándar de ejecución de pruebas de penetración (PTES) proporciona instrucciones sobre escenarios comunes y las actividades necesarias para establecer una línea base.

OWASP Top Ten | OWASP Foundation proporciona procedimientos recomendados de seguridad para aplicaciones y casos de prueba que cubren amenazas comunes.

Lista de comprobación de seguridad

Consulte el conjunto completo de recomendaciones.