Recomendaciones para pruebas de seguridad
Se aplica a esta recomendación de lista de verificación de seguridad bien diseñada: Power Platform
| SE:09 | Establecer un régimen de pruebas integral que combine enfoques para prevenir problemas de seguridad, validar implementaciones de prevención de amenazas y probar mecanismos de detección de amenazas. |
|---|
Las pruebas rigurosas son la base de un buen diseño de seguridad. Las pruebas son una forma táctica de validación para garantizar que los controles funcionen según lo previsto. Las pruebas también son una forma proactiva de detectar vulnerabilidades en el sistema.
Establezca el rigor de las pruebas a través de la cadencia y la verificación desde múltiples perspectivas. Debe incluir puntos de vista desde dentro hacia fuera que prueben la plataforma y la infraestructura y evaluaciones de fuera hacia dentro que prueben el sistema como un atacante externo.
Esta guía proporciona recomendaciones para probar la postura de seguridad de su carga de trabajo. Implemente estos métodos de prueba para mejorar la resistencia de su carga de trabajo a los ataques y mantener la fidencialidad, integridad y disponibilidad de los recursos.
Definiciones
| Término | Definición |
|---|---|
| Pruebas de seguridad de aplicaciones (AST) | Una técnica de ciclo de vida de desarrollo de seguridad (SDL) que utiliza metodologías de prueba de caja blanca y caja negra para verificar vulnerabilidades de seguridad en el código. Microsoft |
| Pruebas de caja negra | Una metodología de prueba que valida el comportamiento de la aplicación visible externamente sin conocimiento de las partes internas del sistema. |
| Equipo azul | Un equipo que defiende de los ataques del equipo rojo en un ejercicio de juegos de guerra. |
| Pruebas de penetración | Una metodología de prueba que utiliza técnicas de piratería ética para validar las defensas de seguridad de un sistema. |
| Equipo rojo | Un equipo que desempeña el papel de adversario e intenta piratear el sistema en un ejercicio de juegos de guerra. |
| Ciclo de vida de desarrollo de seguridad (SDL) | Un conjunto de prácticas proporcionadas por Microsoft que respaldan la garantía de seguridad y los requisitos de cumplimiento. |
| Ciclo de vida de desarrollo del software (SDLC) | Proceso sistemático de varias fases para desarrollar sistemas de software. |
| Pruebas de caja blanca | Una metodología de prueba donde el profesional conoce la estructura del código. |
Estrategias clave de diseño
Las pruebas son una estrategia no negociable, especialmente por motivos de seguridad. Le permite descubrir y abordar proactivamente problemas de seguridad antes de que puedan ser aprovechados y verificar que los controles de seguridad que implementó funcionan según lo diseñado.
El ámbito de las pruebas debe incluir la aplicación, la infraestructura y los procesos humanos y automatizados.
Nota
Esta guía hace una distinción entre pruebas y respuesta a incidentes. Aunque las pruebas son un mecanismo de detección que idealmente soluciona problemas antes de producción, no deben confundirse con la corrección o investigación que se realiza como parte de la respuesta a incidentes. El aspecto de recuperación de incidentes de seguridad se describe en Recomendaciones para responder a incidentes de seguridad.
Participar en la planificación de pruebas. Es posible que el equipo de carga de trabajo no diseñe los casos de prueba. Esa tarea suele estar centralizada en la empresa o ser realizada por expertos externos en seguridad. El equipo de carga de trabajo debe participar en ese proceso de diseño para garantizar que las garantías de seguridad se integren con la funcionalidad de la aplicación.
Piense como un atacante. Diseñe sus casos de prueba asumiendo que el sistema ha sido atacado. De esa manera, puede descubrir vulnerabilidades potenciales y priorizar las pruebas en consecuencia.
Ejecute pruebas de forma estructurada y con un proceso repetible. Sea riguroso en las pruebas en cuanto a cadencia, tipos de pruebas, factores determinantes y resultados previstos.
Utilice la herramienta adecuada para el trabajo. Utilice herramientas que estén configuradas para funcionar con la carga de trabajo. Si no tiene una herramienta, cómprela. No la cree. Las herramientas de seguridad son altamente especializadas y crear su propia herramienta puede presentar riesgos. Aproveche la experiencia y las herramientas que ofrecen los equipos centrales de SecOps o medios externos si el equipo de carga de trabajo no tiene esa experiencia.
Configure entornos separados. Las pruebas se pueden clasificar en destructivas o no destructivas. Las pruebas no destructivas no son invasivas. Indican que hay un problema, pero no alteran la funcionalidad para solucionar el problema. Las pruebas destructivas son invasivas y pueden dañar la funcionalidad eliminando datos de una base de datos.
Las pruebas en entornos de producción le brindan información óptima pero causan una mayor interrupción. Suele realizar únicamente pruebas no destructivas en entornos de producción. Las pruebas en entornos que no son de producción suelen ser menos disruptivas, pero es posible que no representen con precisión la configuración del entorno de producción de forma importante para la seguridad.
Puede crear un clon aislado de su entorno de producción utilizando la característica de copia de entorno. Si tiene canalizaciones de implementación configuradas, también puede implementar sus soluciones en un entorno de prueba dedicado.
Evalúe siempre los resultados de la prueba. Las pruebas son un esfuerzo desperdiciado si los resultados no se utilizan para priorizar acciones y realizar mejoras en los procesos ascendentes. Documente las pautas de seguridad, incluidos los procedimientos recomendados que descubra. La documentación que captura los resultados y los planes de corrección educa al equipo sobre las diversas formas en que los atacantes podrían intentar vulnerar la seguridad. Organice formación periódica sobre seguridad para desarrolladores, administradores y evaluadores.
Cuando diseñe sus planes de prueba, piense en las siguientes preguntas:
- ¿Con qué frecuencia espera que se ejecute la prueba y cómo afecta a su entorno?
- ¿Cuáles son los diferentes tipos de pruebas que debería ejecutar?
¿Con qué frecuencia espera que se ejecuten las pruebas?
Pruebe la carga de trabajo periódicamente para asegurarse de que los cambios no introduzcan riesgos de seguridad y que no haya regresiones. El equipo también debe estar preparado para responder a las validaciones de seguridad organizativas que puedan realizarse en cualquier momento. También hay pruebas que puede ejecutar en respuesta a un incidente de seguridad. En las siguientes secciones se proporcionan recomendaciones sobre la frecuencia de las pruebas.
Pruebas rutinarias
Las pruebas rutinaras se realizan con un ritmo regular, como parte de sus procedimientos operativos estándar y para atender los requisitos de cumplimiento. Se pueden realizar varias pruebas con diferentes cadencias, pero la clave es que se realicen periódicamente y según una programación.
Debe integrar estas pruebas en su SDLC, ya que brindan defensa en profundidad en cada fase. Diversifique el conjunto de pruebas para verificar las garantías de identidad, almacenamiento y transmisión de datos y canales de comunicación. Realice las mismas pruebas en diferentes puntos del ciclo de vida para garantizar que no haya regresiones. Las pruebas rutinarias ayudan a establecer un punto de referencia inicial. Sin embargo, eso es solo un punto de partida. Cuando descubra nuevos problemas en los mismos puntos del ciclo de vida, agregue nuevos casos de prueba. Las pruebas también mejoran con la repetición.
En cada etapa, estas pruebas deben validar el código que se agrega o elimina o las configuraciones que han cambiado para detectar el impacto de esos cambios en la seguridad. Debería mejorar la eficacia de las pruebas con automatización, equilibrada con revisiones entre pares.
Considere la posibilidad de ejecutar pruebas de seguridad como parte de una canalización automatizada o una ejecución de prueba programada. Cuanto antes descubra los problemas de seguridad, más fácil será encontrar el cambio de código o de configuración que los causa.
No confíe únicamente en las pruebas automatizadas. Utilice pruebas manuales para detectar vulnerabilidades que solo la experiencia humana puede detectar. Las pruebas manuales son válidas para casos de uso exploratorios y para encontrar riesgos desconocidos.
Pruebas improvisadas
Las pruebas improvisadas proporcionan una validación puntual de las defensas de seguridad. Las alertas de seguridad que podrían afectar a la carga de trabajo en ese momento activan estas pruebas. Las normas de la organización pueden requerir una metodología de pausa y prueba para verificar la efectividad de las estrategias de defensa si la alerta se convierte en una emergencia.
El beneficio de las pruebas improvisadas es la preparación para un incidente real. Estas pruebas pueden ser una función obligatoria para realizar pruebas de aceptación de usuario (UAT).
El equipo de seguridad podría auditar todas las cargas de trabajo y ejecutar estas pruebas según sea necesario. Como propietario de una carga de trabajo, usted debe facilitar y colaborar con los equipos de seguridad. Negocie plazos suficientes con los equipos de seguridad para tener tiempo de prepararse. Reconozca y comunique a su equipo y a las partes interesadas que estas interrupciones son necesarias.
En otros casos, es posible que deba ejecutar pruebas e informar del estado de seguridad del sistema frente a posibles amenazas.
Compensación: Debido a que las pruebas improvisadas son eventos disruptivos, es posible que sea necesario volver a priorizar las tareas, lo que puede retrasar otros trabajos planificados.
Riesgo: Existe el riesgo de lo desconocido. Las pruebas improvisadas pueden ser esfuerzos puntuales sin procesos ni herramientas establecidos. Pero el riesgo predominante es la posible interrupción del ritmo de los negocios. Es necesario evaluar esos riesgos en relación con los beneficios.
Pruebas de incidentes de seguridad
Existen pruebas que detectan la causa de un incidente de seguridad en su origen. Estas infracciones de seguridad deben resolverse para garantizar que el incidente no se repita.
Los incidentes también mejoran los casos de prueba con el tiempo al descubrir infracciones existentes. El equipo debe aplicar las lecciones aprendidas del incidente e incorporar mejoras de forma rutinaria.
¿Cuáles son los diferentes tipos de pruebas?
Las pruebas se pueden clasificar por tecnología y por metodologías de prueba. Combine esas categorías y enfoques dentro de esas categorías para obtener una cobertura completa.
Al agregar varias pruebas y tipos de pruebas, puede descubrir:
- Infracciones en controles de seguridad o controles compensatorios.
- Errores de configuración.
- Infracciones en observabilidad y métodos de detección.
Un buen ejercicio de modelado de amenazas puede señalar áreas clave para garantizar la cobertura y frecuencia de las pruebas. Para obtener recomendaciones sobre modelado de amenazas, consulte Recomendaciones para garantizar un ciclo de vida de desarrollo.
La mayoría de las pruebas descritas en estas secciones se pueden ejecutar como pruebas rutinarias. Sin embargo, la repetibilidad puede generar costes en algunos casos y causar interrupciones. Considere esas compromisos cuidadosamente.
Pruebas que validan la pila tecnológica
A continuación se muestran algunos ejemplos de tipos de pruebas y sus áreas de enfoque. Esta lista no es exhaustiva. Pruebe toda la pila, incluida la pila de aplicaciones, el front-end, el back-end, las API, las bases de datos y cualquier integración externa.
- Seguridad de los datos: Pruebe la eficacia del cifrado de datos y los controles de acceso para garantizar que los datos estén adecuadamente protegidos contra el acceso no autorizado y la manipulación.
- Red y conectividad: Pruebe sus firewalls para asegurarse de que solo permitan el tráfico esperado, permitido y seguro a la carga de trabajo.
- Aplicación: Pruebe el código fuente a través de técnicas de pruebas de seguridad de aplicaciones (AST) para asegurarse de seguir prácticas de codificación seguras y detectar errores de tiempo de ejecución, como corrupción de memoria y problemas de privilegios.
- Identidad: evaluar si las asignaciones de roles y las comprobaciones condicionales funcionan según lo previsto.
Metodología de prueba
Hay muchas perspectivas sobre las metodologías de prueba. Recomendamos pruebas que permitan la detección de amenazas mediante la simulación de ataques del mundo real. Pueden identificar posibles autores de amenazas, sus técnicas y sus ataques que representan una amenaza para la carga de trabajo. Cree ataques lo más realistas posible. Utilice todos los vectores de amenazas potenciales que identifique durante el modelado de amenazas.
Estas son algunas de las ventajas de realizar pruebas mediante ataques del mundo real:
- Cuando convierte estos ataques en parte de las pruebas rutinarias, utiliza una perspectiva externa para verificar la carga de trabajo y asegurarse de que la defensa pueda resistir un ataque.
- Según las conclusiones aprendidas, el equipo mejora su conocimiento y nivel de habilidades. El equipo mejora el conocimiento de la situación y puede autoevaluar su preparación para responder a incidentes.
Algunos ejemplos de pruebas simuladas incluyen pruebas de caja negra y caja blanca, pruebas de penetración y ejercicios de juegos de guerra.
Pruebas de caja negra y caja blanca
Estos tipos de pruebas ofrecen dos perspectivas diferentes. En las pruebas de caja negra, las partes internas del sistema no son visibles. En las pruebas de caja blanca, el evaluador conoce bien la aplicación e incluso tiene acceso al código, registros, topología de recursos y configuraciones para realizar el experimento.
Pruebas que simulan ataques mediante pruebas de penetración
Los expertos en seguridad que no forman parte de los equipos de aplicaciones o TI de la organización realizan pruebas de penetración o pentesting. Observan el sistema de la misma manera que los atacantes malintencionados analizan una superficie de ataque. Su objetivo es encontrar infracciones de seguridad recopilando información, analizando vulnerabilidades e informando de los resultados.
Es posible que los profesionales necesiten acceso a datos confidenciales de toda la organización. Siga las reglas de involucración para garantizar que no se hace un mal uso del acceso. Consulte los recursos enumerados en Información relacionada.
Pruebas que simulan ataques mediante ejercicios de juegos de guerra
En esta metodología de ataques simulados existen dos equipos:
- El equipo rojo es el adversario que intenta modelar ataques del mundo real. Si tiene éxito, encontrará infracciones en su diseño de seguridad y evaluará la contención del radio de explosión de sus infracciones.
- El equipo azul es el equipo de carga de trabajo que se defiende de los ataques. Ponen a prueba su capacidad para detectar, responder y remediar los ataques. Validan las defensas que se han implementado para proteger los recursos de la carga de trabajo.
Si se llevan a cabo como pruebas de rutina, los ejercicios de juegos de guerra pueden brindar visibilidad continua y garantizar que sus defensas funcionen según lo diseñado. Los ejercicios de juegos de guerra pueden potencialmente probarse en todos los niveles en sus cargas de trabajo.
Una opción popular para simular escenarios de ataque realistas es el Defender para el entrenamiento de simulación de ataques. Microsoft Office 365
Para más información, vea Información e informes para formación en simulación de ataques.
Para obtener información sobre la configuración del equipo rojo y del equipo azul, consulte Microsoft Equipo rojo en la nube.
Facilitación de Power Platform
Microsoft La solución Sentinel permite a los clientes detectar diversas actividades sospechosas, como: Microsoft Power Platform
- Ejecución de Power Apps desde geografías no autorizadas
- Destrucción de datos sospechosos por Power Apps
- Eliminación masiva de Power Apps
- Ataques de phishing realizados a través de Power Apps
- Actividad de flujos de Power Automate de empleados que abandonan la empresa
- Conectores de Microsoft Power Platform agregados a un entorno
- Actualización o eliminación de directivas de prevención de pérdida de datos de Microsoft Power Platform
Para obtener más información, consulte la Microsoft solución Sentinel para obtener una descripción general Microsoft Power Platform .
Para consultar la documentación del producto, consulte Capacidades de caza en Microsoft Sentinel.
Microsoft Defender for Cloud ofrece escaneo de vulnerabilidades para diversas áreas tecnológicas. Para obtener más información, consulte Habilitar el análisis de vulnerabilidades con Microsoft Defender Vulnerability Management.
La práctica de DevSecOps integra las pruebas de seguridad en el marco de una mentalidad de mejora continua y continua. Los ejercicios de juegos de guerra son una práctica común que está integrada al ritmo de los negocios en Microsoft. Para obtener más información, consulte Seguridad en DevOps (DevSecOps).
Azure DevOps admite herramientas de terceros que se pueden automatizar como parte de los procesos de integración/implementación continua (CI/CD). Para más información, vea Habilitar DevSecOps con Azure y GitHub.
Información relacionada
Las últimas pruebas de penetración y evaluaciones de seguridad se pueden encontrar en el Microsoft Portal de confianza del servicio.
Microsoft Realiza pruebas exhaustivas de los servicios en la nube. Microsoft Esta prueba incluye pruebas de penetración, cuyos resultados se publican en el Portal de confianza del servicio de su organización. Su organización puede realizar su propia prueba de penetración en servicios de Microsoft Power Platform y Microsoft Dynamics 365. Todas las pruebas de penetración deben cumplir las Microsoft Reglas de participación en pruebas de penetración en la nube. Es importante recordar que en muchos casos, la Nube utiliza infraestructura compartida para alojar sus activos y los activos de otros clientes. Microsoft Debe limitar todas las pruebas de penetración a sus activos y evitar consecuencias no deseadas para otros clientes a su alrededor.
Siga las reglas de involucración para garantizar que no se hace un mal uso del acceso. Para obtener orientación sobre la planificación y ejecución de ataques simulados, consulte:
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 protección contra DDoS de Azure.
Lista de verificación de seguridad
Consulte el conjunto completo de recomendaciones.