Recomendaciones para pruebas de seguridad
Se aplica a esta recomendación de lista de comprobación de seguridad de Azure Well-Architected Framework:
| SE:11 | Establezca un régimen de pruebas completo que combine enfoques para evitar problemas de seguridad, validar las implementaciones de prevención de amenazas y probar los mecanismos de detección de amenazas. |
|---|
Las pruebas rigurosas son la base del buen diseño de seguridad. Las pruebas son una forma táctica de validación para asegurarse de que los controles funcionan según lo previsto. 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. Debe incluir puntos de vista dentro de fuera que prueben la plataforma y la infraestructura y las evaluaciones externas que prueben el sistema como un atacante externo.
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.
Definiciones
| Término | Definición |
|---|---|
| Pruebas de seguridad de aplicaciones (AST) | Técnica del ciclo de vida de desarrollo de seguridad (SDL) de Microsoft que usa metodologías de pruebas de caja blanca y de caja negra para comprobar si hay vulnerabilidades de seguridad en el código. |
| Pruebas de caja negra | Metodología de prueba que valida el comportamiento de la aplicación visible externamente sin conocer los elementos internos del sistema. |
| Equipo azul | Un equipo que defiende los ataques del equipo rojo en un ejercicio de juego de guerra. |
| Pruebas de penetración | Metodología de prueba que usa técnicas éticas de piratería para validar las defensas de seguridad de un sistema. |
| Equipo rojo | Un equipo que desempeña el papel de un adversario e intenta hackear el sistema en un ejercicio de juego de guerra. |
| Ciclo de vida del desarrollo de seguridad de Microsoft | Conjunto de prácticas proporcionadas por Microsoft que admiten requisitos de cumplimiento y garantía de seguridad. |
| Ciclo de vida de desarrollo de software (SDLC) | Un proceso sistemático de varias fases para desarrollar sistemas de software. |
| Pruebas de caja blanca | Metodología de prueba en la que se conoce la estructura del código al profesional. |
Estrategias de diseño principales
Las pruebas son una estrategia no negociable, especialmente para la seguridad. Permite detectar y solucionar de forma proactiva los problemas de seguridad antes de que se puedan aprovechar y comprobar que los controles de seguridad implementados funcionan según lo diseñado.
El ámbito de las pruebas debe incluir la aplicación, la infraestructura y los procesos automatizados y humanos.
Nota
Esta guía distingue entre las pruebas y la respuesta a incidentes. Aunque las pruebas son un mecanismo de detección que idealmente corrige los problemas antes de la producción, no debe confundirse con la corrección o investigación que se realiza como parte de la respuesta a incidentes. El aspecto de la recuperación de incidentes de seguridad se describe en recomendaciones de respuesta a incidentes.
SDL incluye varios tipos de pruebas que detectan vulnerabilidades en el código, comprueban los componentes en tiempo de ejecución y usan piratería ética para probar la resistencia de seguridad del sistema. SDL es una actividad de desplazamiento a la izquierda de teclas. Debe ejecutar pruebas como el análisis de código estático y el análisis automatizado de la infraestructura como código (IaC) tan pronto como sea posible en el proceso de desarrollo.
Participe 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 completada por expertos de seguridad externos. 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.
Piensa como un atacante. Diseñe los casos de prueba con la suposición de que se ha atacado el sistema. De este modo, puede descubrir las posibles vulnerabilidades y priorizar las pruebas en consecuencia.
Ejecute pruebas de forma estructurada y con un proceso repetible. Cree el rigor de las pruebas en torno a la cadencia, los tipos de pruebas, los factores de conducción y los resultados previstos.
Use la herramienta adecuada para el trabajo. Use herramientas configuradas para trabajar con la carga de trabajo. Si no tiene una herramienta, compre la herramienta. No lo compiles. Las herramientas de seguridad son muy especializadas y la creación de su propia herramienta podría presentar riesgos. Aproveche la experiencia y las herramientas que ofrecen los equipos centrales de SecOps o por medios externos si el equipo de carga de trabajo no tiene esa experiencia.
Configure entornos independientes. Las pruebas se pueden clasificar como destructivas o no destructivas. Las pruebas no destructivas no son invasivas. Indican que hay un problema, pero no modifican la funcionalidad para corregir el problema. Las pruebas destructivas son invasivas y pueden dañar la funcionalidad mediante la eliminación de datos de una base de datos.
Las pruebas en entornos de producción proporcionan la mejor información, pero provocan la mayor interrupción. Solo se suelen realizar pruebas no destructivas en entornos de producción. Las pruebas en entornos que no son de producción suelen ser menos perjudiciales, pero podrían no representar con precisión la configuración del entorno de producción de maneras importantes para la seguridad.
Si implementa mediante IaC y automatización, tenga en cuenta si puede crear un clon aislado del entorno de producción para las pruebas. Si tiene un proceso continuo para las pruebas rutinarias, se recomienda usar un entorno dedicado.
Evalúe siempre los resultados de la prueba. Las pruebas son un esfuerzo desperdiciado si los resultados no se usan para priorizar las acciones y realizar mejoras ascendentes. Documente las directrices de seguridad, incluidos los procedimientos recomendados, que descubra. Documentación que captura los resultados y los planes de corrección instruyen al equipo sobre las distintas formas en que los atacantes podrían intentar infringir la seguridad. Realice una formación de seguridad periódica para desarrolladores, administradores y evaluadores.
Al diseñar los planes de prueba, piense en las siguientes preguntas:
¿Con qué frecuencia espera que se ejecute la prueba y cómo afecta al entorno?
¿Cuáles son los distintos tipos de prueba que debe ejecutar?
¿Con qué frecuencia espera que se ejecuten las pruebas?
Pruebe la carga de trabajo con regularidad para asegurarse de que los cambios no presentan riesgos de seguridad y que no hay regresiones. El equipo también debe estar listo para responder a las validaciones de seguridad de la organización que se pueden llevar a cabo en cualquier momento. También hay pruebas que puede ejecutar en respuesta a un incidente de seguridad. En las secciones siguientes se proporcionan recomendaciones sobre la frecuencia de las pruebas.
Pruebas rutinarias
Las pruebas rutinarias se realizan a una cadencia regular, como parte de los procedimientos operativos estándar y para cumplir los requisitos de cumplimiento. Es posible que varias pruebas se ejecuten con diferentes cadencias, pero la clave es que se llevan a cabo periódicamente y según una programación.
Debe integrar estas pruebas en el SDLC porque proporcionan defensa en profundidad en cada fase. Diversifique el conjunto de pruebas para comprobar las garantías de identidad, almacenamiento y transmisión de datos y canales de comunicación. Realice las mismas pruebas en distintos puntos del ciclo de vida para asegurarse de que no haya ninguna regresión. Las pruebas rutinarias ayudan a establecer una prueba comparativa inicial. Sin embargo, eso es sólo un punto de partida. Al descubrir nuevos problemas en los mismos puntos del ciclo de vida, se agregan nuevos casos de prueba. Las pruebas también mejoran con repetición.
En cada fase, estas pruebas deben validar el código agregado o quitado o las opciones de configuración que han cambiado para detectar el impacto en la seguridad de esos cambios. Debe mejorar la eficacia de las pruebas con automatización, equilibrada con revisiones del mismo nivel.
Considere la posibilidad de ejecutar pruebas de seguridad como parte de una canalización automatizada o una ejecución de pruebas programadas. Cuanto antes detecte problemas de seguridad, más fácil es encontrar el código o el cambio de configuración que los provoca.
No confíe solo en pruebas automatizadas. Use pruebas manuales para detectar vulnerabilidades que solo pueden detectar conocimientos humanos. Las pruebas manuales son adecuadas para casos de uso exploratorios y para encontrar 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 para 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 podría 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. Negocie el tiempo de entrega suficiente con los equipos de seguridad para que pueda prepararse. 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.
Equilibrio: dado que las pruebas improvisadas son eventos perjudiciales, espere volver a escribir las tareas, lo que puede retrasar otro trabajo planeado.
Riesgo: existe el riesgo de que se desconoce. Las pruebas improvisadas pueden ser esfuerzos puntuales sin procesos o herramientas establecidos. Pero el riesgo predominante es la posible interrupción del ritmo del negocio. Debe evaluar esos riesgos en relación con las ventajas.
Pruebas de incidentes de seguridad
Hay pruebas que detectan la causa de un incidente de seguridad en su origen. Estas brechas de seguridad deben resolverse para asegurarse de que el incidente no se repite.
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.
¿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:
Brechas en los controles de seguridad o en los controles de compensación.
Configuraciones incorrectas.
Brechas en los métodos de observabilidad y detección.
Un buen ejercicio de modelado de amenazas puede apuntar a áreas clave para garantizar 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.
La mayoría de las pruebas descritas en estas secciones se pueden ejecutar como pruebas rutinarias. Sin embargo, la repetibilidad puede incurrir en costos en algunos casos y provocar interrupciones. Tenga en cuenta esos inconvenientes cuidadosamente.
Pruebas que validan la pila de tecnología
Estos son 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 las integraciones externas.
Seguridad de los datos: pruebe la eficacia del cifrado de datos y los controles de acceso para asegurarse de que los datos están protegidos correctamente contra el acceso no autorizado y la manipulación.
Red y conectividad: pruebe los firewalls para asegurarse de que solo permiten el tráfico esperado, permitido y seguro a la carga de trabajo.
Aplicación: pruebe el código fuente mediante técnicas de prueba de seguridad de aplicaciones (AST) para asegurarse de seguir 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 más información, consulte estos vínculos de la comunidad.
Identidad: evalúe 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. Se recomiendan pruebas que permiten la búsqueda de amenazas mediante la simulación de ataques reales. Pueden identificar posibles actores de amenazas, sus técnicas y sus vulnerabilidades de seguridad que suponen una amenaza para la carga de trabajo. Haga 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 aprendidas, el equipo actualiza sus conocimientos y nivel de aptitud. El equipo mejora el conocimiento de la situación y puede evaluar automáticamente su preparación para responder a incidentes.
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 caja blanca
Estos tipos de prueba ofrecen dos perspectivas diferentes. En las pruebas de caja negra, los elementos internos del sistema no son 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 llevar a cabo el experimento.
Pruebas que simulan ataques a través de pruebas de penetración
Los expertos en seguridad que no forman parte de los equipos de TI o aplicación de la organización realizan pruebas de penetración o pruebas de lápiz. Examinan el sistema de la manera en que los actores malintencionados limitan una superficie expuesta a ataques. 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.
Es posible que los profesionales necesiten acceso a datos confidenciales en toda la organización. Siga las reglas de involucración para asegurarse de que el acceso no se usa incorrectamente. Consulte los recursos que aparecen en vínculos relacionados.
Pruebas que simulan ataques a través de ejercicios de juego de guerra
En esta metodología de ataques simulados, hay dos equipos:
El equipo rojo es el adversario que intenta modelar ataques reales. Si tienen éxito, encontrará lagunas en el 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 defiende los ataques. Prueban su capacidad de detectar, responder y corregir los ataques. Validan las defensas que se han implementado para proteger los recursos de carga de trabajo.
Si se llevan a cabo como pruebas rutinarias, los ejercicios de juego de guerra pueden proporcionar visibilidad y garantía continuas de que sus defensas funcionan según lo diseñado. Los ejercicios de juego de guerra pueden probar potencialmente entre niveles dentro de las cargas de trabajo.
Una opción popular para simular escenarios de ataque realistas es el Microsoft Defender para Office 365 Entrenamiento de simulación de ataque.
Para obtener más información, consulte Información e informes para Entrenamiento de simulación de ataque.
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 registros de varios orígenes conectados. En función de los orígenes de datos y sus alertas, Microsoft Sentinel crea incidentes y realiza 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, con plantillas de libro, puede obtener información rápidamente a través de la visualización.
Para obtener documentación del producto, consulte Funcionalidades de búsqueda en Microsoft Sentinel.
Microsoft Defender for Cloud ofrece un examen de vulnerabilidades para diversas áreas tecnológicas. Para más información, consulte Habilitación del examen de vulnerabilidades con Administración de vulnerabilidades de Microsoft Defender: Microsoft Defender for Cloud.
La práctica de DevSecOps integra las 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, vea Seguridad en DevOps (DevSecOps) .
Azure DevOps admite herramientas de terceros que se pueden 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 reglas de involucración para asegurarse de que el acceso no se usa incorrectamente. Para obtener instrucciones sobre cómo planear y ejecutar ataques simulados, consulte los siguientes artículos:
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 en tiempo de ejecución de la aplicación.
En Estándar de ejecución de pruebas de penetración (PTE) se proporcionan directrices sobre escenarios comunes y las actividades necesarias para establecer una línea de 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.
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de