Introducción al marco de certificación de Microsoft 365
En este artículo se proporciona información detallada sobre la certificación de Microsoft 365, incluida una lista de los controles de seguridad necesarios y las instrucciones para isv y desarrolladores.
La certificación de Microsoft 365 es una auditoría de seguridad y privacidad independiente de aplicaciones, complementos y entorno back-end compatible (denominados colectivamente aplicaciones) que se integra con la plataforma Microsoft 365. Las aplicaciones que pasen se designarán con certificación de Microsoft 365 en todo el ecosistema de Microsoft 365 y se pueden encontrar fácilmente en los marketplaces de Microsoft 365 a través de filtros de búsqueda centrados en el cumplimiento y personalización de marca. Los ISV tendrán la oportunidad de compartir los atributos de cumplimiento de su aplicación en páginas dedicadas dentro de este conjunto de documentación.
La certificación de Microsoft 365 está disponible para los siguientes tipos de aplicaciones:
- Complementos de Microsoft 365 (Word, Excel, Outlook, PowerPoint, OneNote, Project)
- Aplicaciones de Teams
- Soluciones de SharePoint
- Aplicaciones web (SaaS)
- Extensiones de CoPilot
Importante
La certificación de Microsoft 365 es una revisión rigurosa de la seguridad y el cumplimiento de una aplicación con respecto al marco de certificación de Microsoft 365 y requiere un tiempo y un compromiso de recursos sustanciales para completarse. Antes de empezar, revise los marcos de control de cumplimiento para comprobar que la aplicación es apta. Si tiene alguna pregunta, envíe un correo electrónico appcert@microsoft.coma .
Letra chica
Al participar en el programa de certificación de Microsoft 365, acepta estos términos complementarios y cumple con cualquier documentación adjunta que se aplique a su participación en el programa de certificación de Microsoft 365 con Microsoft Corporation ("Microsoft", "nosotros", "nosotros" o "nuestro"). Usted nos declara y garantiza que tiene la autoridad para aceptar estos términos complementarios de certificación de Microsoft 365 en nombre de usted mismo, una empresa y/u otra entidad, según corresponda. Podemos cambiar, modificar o finalizar estos términos complementarios en cualquier momento. Su participación continua en el programa de certificación de Microsoft 365 después de cualquier cambio o modificación significa que acepta los nuevos términos complementarios. Si no acepta los nuevos términos complementarios o si finalizamos estos términos complementarios, debe dejar de participar en el programa de certificación de Microsoft 365.
Requisitos previos
Antes de que se pueda conceder la certificación de Microsoft 365, una aplicación debe completar lo siguiente:
Comprobación del publicador Cuando una aplicación tiene un publicador comprobado, Microsoft ha comprobado que la organización que publica la aplicación es auténtica. La comprobación de una aplicación incluye el uso de una cuenta del Programa de partners en la nube (CPP) de Microsoft que se ha comprobado y la asociación del Id. de asociado comprobado con un registro de aplicación. Obtención de la comprobación del publicador
La atestación de publicador es un proceso de autoservicio en el que los desarrolladores de aplicaciones (ISV) completan un conjunto de preguntas sobre sus prácticas de seguridad, como el control de datos confidenciales. Una vez completada, la aplicación recibirá anuncios y errores especiales en el marketplace de Microsoft AppSource.
Revisión de los criterios de control No siempre es un requisito cumplir con todos los controles para obtener una certificación. Sin embargo, los umbrales (que no se divulgarán) están establecidos para cada uno de los tres dominios de seguridad descritos en este documento de información general y deben pasarse. Si no se cumplen los controles críticos etiquetados como "error grave", se producirá un error en la evaluación.
Período de tiempo de envío
Hay dos fases en el proceso de envío para lograr la certificación:
Fase 1: Envío inicial de documentos (período de tiempo de 14 días)
En esta fase, el ISV debe enviar documentación que proporcione información general sobre el entorno de soporte técnico de sus aplicaciones. Esto incluye, pero no se limita a:
- Diagrama de arquitectura/Flujo de datos
- Listas de componentes del sistema
- Inventarios de activos de software
Un analista revisará esta documentación para definir el ámbito de la evaluación. El ISV tiene 14 días para completar y cargar la documentación necesaria. El incumplimiento de esta fecha límite puede retrasar el proceso o dar lugar a un envío con errores.
Fase 2: Revisión completa de pruebas (período de tiempo de 60 días)
Una vez definido el ámbito, el ISV pasará a la fase de recopilación de evidencias. En esta fase:
- El ISV debe cargar pruebas en todos los controles aplicables definidos desde el ámbito.
- Esta evidencia se someterá a revisión, revisiones (si es necesario) y un proceso final de control de calidad.
- Si es necesario, las pruebas de penetración también se pueden realizar durante este tiempo.
El ISV tiene 60 días para completar esta fase, a partir de la primera presentación de pruebas, que incluye:
- Carga de pruebas para todos los controles
- Comentarios y revisión de analistas
- Todas las revisiones necesarias para presentar pruebas
- Finalización del proceso de control de calidad
Error al cumplir la fecha límite
Si el ISV no puede completar el proceso dentro del período de tiempo de 60 días, se producirá un error en la evaluación. Sin embargo, a discreción del analista, se puede conceder una extensión de hasta 60 días adicionales en circunstancias válidas, como:
- Vacaciones de temporada.
- Retrasos en las pruebas de penetración.
- Cambios internos.
- Tiempo necesario para implementar los cambios necesarios para cumplir los requisitos de control.
No se pueden conceder más extensiones, una vez agotados los dos períodos de tiempo de 60 días.
Ámbito de certificación
El entorno en ámbito abarca todos los sistemas y la infraestructura necesarios para entregar el código de aplicación o complemento, junto con cualquier sistema back-end compatible con el que la aplicación o el complemento puedan comunicarse. Los entornos adicionales conectados al entorno dentro del ámbito también deben incluirse en el ámbito a menos que se implemente una segmentación adecuada y los entornos conectados no puedan poner en peligro la seguridad del entorno dentro del ámbito.
Tenga en cuenta que los entornos de recuperación ante desastres independientes también deben incluirse en el entorno dentro del ámbito, ya que estos entornos pueden ser fundamentales para mantener la continuidad del servicio en caso de errores del entorno principal.
Además, los entornos de copia de seguridad remota también deben incorporarse al ámbito, ya que pueden almacenar datos confidenciales de Microsoft. Por lo tanto, se deben implementar controles de seguridad adecuados para estos entornos.
El término componentes del sistema en el ámbito incluye todos los dispositivos y sistemas que se usan activamente en el entorno definido en el ámbito. Estos componentes incluyen, entre otros:
- Aplicaciones web
- Servidores (físicos o virtuales, ubicados en el entorno local o en la nube)
- Modificadores
- Equilibradores de carga
- Infraestructura virtual
- Portales de administración web del proveedor de nube
- Recursos en la nube (Virtual Machines, App Services, cuentas de almacenamiento, bases de datos, etc.)
Importante
Los componentes del sistema orientados al público son especialmente vulnerables a ataques por parte de actores de amenazas externos y, por tanto, a un mayor riesgo. Normalmente, estos sistemas deben aislarse de los componentes internos del sistema mediante la implementación de controles de seguridad de red (NSC), como una zona desmilitarizada (DMZ). El propósito de una red perimetral es actuar como zona de búfer, limitando la confianza extendida a los sistemas externos y mejorando la seguridad para proteger los datos y los sistemas internos. Aunque una red perimetral puede seguir siendo ideal en algunos casos, las arquitecturas modernas de nube a menudo se basan en medidas de seguridad alternativas adaptadas a escenarios de implementación específicos.
Infraestructura como servicio (IaaS), Plataforma como servicio (PaaS) y Software como servicio (SaaS)
Cuando IaaS o PaaS se usan para admitir el entorno en el ámbito que se está revisando, el proveedor de la plataforma en la nube será responsable de algunos de los controles de seguridad evaluados a lo largo del proceso de certificación. El proveedor de la plataforma en la nube deberá proporcionar a los analistas una verificación externa independiente de los procedimientos recomendados de seguridad a través de informes de cumplimiento externos, como PCI DSS, atestación de cumplimiento (AOC), informes ISO 27001 o SOC 2 de tipo II.
Para obtener más información sobre qué controles de seguridad son probables aplicables al tipo de implementación y si el entorno procesa o transfiere datos de Microsoft 365, consulte el Apéndice C. Los tipos de implementación incluyen:
Hospedado por ISV: aplicación hospedada por iaas de iaas de proveedores de software independientes: infraestructura proporcionada por plataformas en la nube de terceros. PaaS/Hosted sin servidor: las aplicaciones promedian la arquitectura basada en plataformas o sin servidor. Hospedado híbrido: una combinación de componentes locales y hospedados en la nube. Hospedado compartido: entornos en la nube compartidos utilizados por varios inquilinos.
En los casos en los que IaaS o PaaS están en uso, la evidencia debe validar que la implementación se alinea con los controles de seguridad esperados para la arquitectura pertinente.
Muestreo
Para garantizar una evaluación exhaustiva, el muestreo de los componentes del sistema en el ámbito debe tener en cuenta factores como los sistemas operativos, la función del dispositivo principal, el tipo de dispositivo (por ejemplo, servidores, enrutadores, controles de seguridad de red) y la ubicación geográfica. Los ejemplos se seleccionan al principio del proceso de certificación en función de estas consideraciones. En la tabla siguiente se guía el tamaño de muestreo en función de la población de componentes dentro del ámbito:
| Tamaño de población | Muestra |
|---|---|
| <=5 | 1 |
| >5 & <10= | 2 |
| >10 & <=30 | 3 |
| >30 | 4 |
Esto garantiza una evaluación representativa del cumplimiento del entorno en diversas configuraciones y modelos de implementación.
Nota:
Si se identifican discrepancias entre los dispositivos durante la evaluación, el tamaño de la muestra se puede ajustar para garantizar una presentación adecuada del entorno.
Introducción al proceso de certificación
Para comenzar el proceso de certificación de Microsoft 365:
Atestación del publicador Vaya al Centro de partners y complete el formulario de atestación del publicador. Nota: Si el envío tiene más de tres meses, debe volver a enviarlo para su revisión y validación.
Iniciar certificación Una vez en el Centro de partners, seleccione la opción "Iniciar certificación" para comenzar el envío inicial de documentos. Este paso ayuda a los analistas de certificación a identificar el ámbito de la evaluación en función de la arquitectura de la aplicación y de cómo administra los datos de Microsoft.
La certificación se lleva a cabo en dos fases principales:
Envío inicial de documentos En esta fase, proporciona detalles clave para ayudar a los analistas a comprender el diseño, el flujo de datos y el entorno dentro del ámbito de la aplicación. Los analistas determinarán los controles de seguridad aplicables y describirán los componentes del sistema que requieren pruebas. Debe proporcionar documentación precisa para facilitar esta revisión, que representa aproximadamente el 5 % del proceso general.
Revisión completa de pruebas En esta fase, envía pruebas detalladas que muestran el cumplimiento de los controles de seguridad para el entorno dentro del ámbito. Los analistas trabajarán estrechamente con usted durante esta fase para revisar, aclarar y comprobar los envíos. Esta fase toma el resto del proceso.
Evaluación
Una vez aprobado el envío inicial de documentos, aparecerá una lista de los controles de seguridad necesarios en el portal. Tiene 60 días para proporcionar pruebas para cada control, confirmando que está en vigor y operativo. Los analistas revisarán las pruebas y la aprobarán o solicitarán detalles o revisiones adicionales.
Certificación
Una vez que un analista haya revisado y validado el envío, recibirá una notificación sobre la decisión de certificación. Las aplicaciones que cumplan correctamente los criterios de certificación recibirán un distintivo, que se mostrará en su lista de AppSource y en las páginas de Microsoft Docs asociadas. Estas páginas también proporcionarán informes detallados sobre los atributos de seguridad y cumplimiento de la aplicación.
Revisión y recertificación
Las aplicaciones certificadas de Microsoft 365 deben someterse a una recertificación anual para garantizar el cumplimiento continuo de los estándares de Microsoft. El proceso de recertificación implica volver a evaluar los controles en el ámbito para confirmar que se alinean con el entorno actual. Puede comenzar el proceso de recertificación hasta 90 días antes de que expire la certificación para evitar interrupciones. Las certificaciones seguirán siendo válidas durante este período.
Si la recertificación no se completa antes de la fecha de expiración, se revocará la certificación. Como resultado:
Se quitarán el distintivo de certificación y la personalización de marca de la aplicación.
Los ISV ya no podrán comercializar la aplicación como Microsoft 365 Certified.
Si hay cambios significativos en la aplicación fuera del período de recertificación programado, los ISV deben informar al Programa de cumplimiento de aplicaciones de Microsoft para asegurarse de que la aplicación sigue siendo compatible.
Envío inicial de documentos
El envío inicial debe incluir la siguiente información:
| Introducción a la documentación | Detalles de la documentación |
|---|---|
| Descripción de aplicación o complemento | Descripción del propósito y la funcionalidad de la aplicación o complemento. Esto debe proporcionar al analista de certificación una buena comprensión de cómo funciona la aplicación o el complemento y cuál es su uso previsto |
| Informe de pruebas de penetración | Un informe de pruebas de penetración completado en los últimos 12 meses. Este informe debe incluir el entorno que admite la implementación de la aplicación o agregar junto con cualquier entorno adicional que admita el funcionamiento de la aplicación o el complemento. Nota: si el ISV no realiza actualmente pruebas de penetración anuales, Microsoft cubrirá el costo de las pruebas de lápiz a través del proceso de certificación. |
| Diagramas de arquitectura | Diagrama de arquitectura lógica que representa una visión general de alto nivel de la infraestructura auxiliar de la aplicación. Esto debe incluir todos los entornos de hospedaje y la infraestructura compatible con la aplicación. Este diagrama DEBE representar todos los distintos componentes del sistema auxiliares dentro del entorno para ayudar a los analistas de certificación a comprender los sistemas en el ámbito y ayudar a determinar el muestreo. Indique también qué tipo de entorno de hospedaje se usa; Hospedado por ISV, IaaS, PaaS o híbrido. Nota: Cuando se use SaaS, indique los diversos servicios SaaS que se usan para proporcionar servicios auxiliares dentro del entorno. |
| Huella pública | Detalles de todas las direcciones IP públicas y direcciones URL usadas por la infraestructura auxiliar. Esto debe incluir el intervalo ip enrutable completo asignado al entorno a menos que se haya implementado una segmentación adecuada para dividir el intervalo en uso (se necesitarán pruebas adecuadas de segmentación). |
| Diagramas de flujo de datos | Diagramas de flujo que detallan lo siguiente: |
| ✓ Flujos de datos de Microsoft 365 hacia y desde la aplicación o complemento ( incluidos EUII y OII). | |
| ✓ Flujos de datos de Microsoft 365 dentro de la infraestructura auxiliar (si procede). | |
| ✓ Diagramas que resaltan dónde y qué datos se almacenan, cómo se pasan los datos a terceros externos (incluidos los detalles de qué terceros) y cómo se protegen los datos en tránsito a través de redes públicas y abiertas y en reposo. | |
| Detalles del punto de conexión de API | Una lista completa de todos los puntos de conexión de API usados por la aplicación. Para ayudar a comprender el ámbito del entorno, proporcione ubicaciones de punto de conexión de API dentro del entorno. |
| Permisos de API de Microsoft | Proporcione documentación en la que se detallan TODAS las API de Microsoft que se usan junto con los permisos que se solicitan para que la aplicación o el complemento funcionen junto con una justificación para los permisos solicitados. |
| Tipos de almacenamiento de datos | Almacenamiento y control de datos de documentos que describen lo siguiente: |
| ✓ ¿Hasta qué punto se reciben y almacenan los datos EUII y OII de Microsoft 365? | |
| ✓ Período de retención de datos. | |
| ✓ Por qué se capturan los datos de Microsoft 365. | |
| ✓ Donde se almacenan los datos de Microsoft 365 (también debe incluirse en los diagramas de flujo de datos proporcionados anteriormente). | |
| Confirmación de cumplimiento | Documentación de soporte técnico para marcos de seguridad externos incluidos en el envío de atestación del publicador o que se debe tener en cuenta al revisar los controles de seguridad de certificación de Microsoft 365. Actualmente, se admiten los cuatro siguientes: |
| ✓ Certificación de cumplimiento (AOC) de PCI DSS . | |
| ✓ SOC 2 Informes de tipo I/Tipo II. | |
| ✓ ISMS / IEC - 1S0/IEC 27001 Declaración de aplicabilidad (SoA) y certificación. | |
| ✓ FedRAMP FedRAMP Authorization Package and FedRAMP Readiness Assessment Report. | |
| Dependencias web | Documentación que enumera todas las dependencias usadas por la aplicación con las versiones en ejecución actuales. |
| Inventario de software | Un inventario de software actualizado que incluye todo el software usado en el entorno dentro del ámbito junto con las versiones. |
| Inventario de hardware | Un inventario de hardware actualizado que usa la infraestructura auxiliar. Esto se usará para ayudar con el muestreo al realizar la fase de evaluación. Si el entorno incluye PaaS, proporcione detalles de los servicios o recursos en la nube consumidos. |
Actividades de recopilación y evaluación de evidencias
Los analistas de certificación tendrán que revisar las pruebas en todos los componentes del sistema dentro del conjunto de ejemplo definido. Entre los tipos de pruebas necesarias para respaldar el proceso de evaluación se incluyen las siguientes:
Colección de evidencias
- Documentación inicial, resaltada en la guía de envío de documentación inicial
- Documentos de directiva
- Procesar documentos
- Configuración del sistema
- Cambiar vales
- Cambiar registros de control
- Informes del sistema
- Minutos de reunión
- Contratos o contratos
Se usarán varios métodos para recopilar las pruebas necesarias para completar el proceso de evaluación. Esta colección de evidencias puede tener la forma de:
- Documentos
- Capturas de pantalla
- Entrevistas
- Screensharing
Las técnicas de recopilación de pruebas utilizadas se determinarán durante el proceso de evaluación. Para obtener ejemplos específicos del tipo de evidencia necesaria en el envío, consulte la Guía de evidencia de ejemplo.
Actividades de evaluación
Los analistas de certificación revisarán las pruebas enviadas para comprobar que se cumplen todos los controles necesarios para la certificación de Microsoft 365. Para acelerar el proceso, asegúrese de que toda la documentación especificada en el envío de documentación inicial está completa y proporcionada con antelación.
Durante la revisión, los analistas evaluarán las pruebas del envío inicial y la atestación del publicador. Determinarán el ámbito de la investigación, el lado de muestreo y si son necesarias pruebas adicionales. Los analistas usarán toda la información recopilada para evaluar el cumplimiento de la especificación de certificación de Microsoft 365 y decidir si la aplicación cumple los controles definidos.
Criterios de certificación de aplicaciones
La aplicación y su infraestructura auxiliar y la documentación auxiliar se evaluarán en los tres dominios de seguridad siguientes:
- Seguridad de la aplicación
- Seguridad operativa/implementación segura
- Control de datos de seguridad y privacidad
Cada uno de estos dominios de seguridad incluye controles clave específicos que abarcan uno o varios requisitos que se evaluarán como parte del proceso de evaluación. Para asegurarse de que la certificación de Microsoft 365 sea inclusiva para desarrolladores de todos los tamaños, cada uno de los dominios de seguridad se evalúa mediante un sistema de puntuación para determinar una puntuación general de cada uno de los dominios. Las puntuaciones de cada uno de los controles de certificación de Microsoft 365 se asignan entre 1 (bajo) y 3 (alto) en función del riesgo percibido de que ese control no se implemente. Cada uno de los dominios de seguridad tendrá un porcentaje mínimo que se considerará un pase. Algunos factores dan lugar a errores automáticos, incluidos
Uso de permisos de API que no cumplen el principio de privilegios mínimos (PoLP)
Falta de informes de pruebas de penetración cuando es necesario.
Ausencia de defensas antimalware.
Error al implementar la autenticación multifactor (MFA) para el acceso administrativo.
Faltan procesos de aplicación de revisiones o no son suficientes.
Falta de aviso de privacidad del RGPD conforme.
Seguridad de la aplicación
El dominio de seguridad de la aplicación evalúa las siguientes áreas:
- Validación de permisos de GraphAPI
- Comprobaciones de conectividad externa
- Pruebas de penetración
Validación de permisos de GraphAPI
Esto garantiza que la aplicación o el complemento no solicite permisos excesivos o excesivamente permisivos. Los analistas de certificación revisan manualmente los permisos solicitados por la aplicación y los comprueban en el envío de atestación del publicador.
El objetivo es confirmar que los permisos solicitados cumplen el principio de privilegios mínimos. Si los analistas detectan que la aplicación solicita permisos que superan lo necesario, se pondrán en contacto con el ISV para validar la justificación empresarial de estos permisos. Las discrepancias identificadas entre los permisos solicitados y el envío de atestación del publicador deben abordarse y resolverse durante esta revisión.
Comprobaciones de conectividad externa
Como parte del proceso de certificación, los analistas realizan una revisión de alto nivel de la funcionalidad de la aplicación para identificar las conexiones externas realizadas fuera de Microsoft 365.
Las conexiones que no se identifiquen como servicios de Microsoft o que no estén relacionadas con el servicio se marcarán durante la evaluación para garantizar el cumplimiento de los estándares de seguridad y funcionalidad.
Pruebas de penetración
Las pruebas de penetración son fundamentales para identificar y mitigar los riesgos asociados con la aplicación o el complemento y su entorno auxiliar. Esto garantiza que la aplicación proporciona garantías de seguridad adecuadas a los clientes.
Las pruebas de penetración son obligatorias para cualquier aplicación que se conecte a servicios externos no hospedados o administrados por Microsoft. Si la aplicación se implementa como una solución independiente que solo usa servicios de Microsoft como GraphAPI, es posible que no se requieran pruebas de penetración. Sin embargo, las aplicaciones hospedadas en Azure deben someterse a pruebas de penetración para garantizar la seguridad del entorno dentro del ámbito.
Ámbito de pruebas de penetración
Pruebas de infraestructura: para la infraestructura interna y externa, las pruebas de penetración se deben realizar en el entorno de producción en vivo que admite la aplicación o el complemento. Esto incluye lo siguiente:
Entorno en el que se hospeda el código de la aplicación o del complemento (normalmente se hace referencia a él en el archivo de manifiesto)
Cualquier entorno adicional que interactúe con o admita el funcionamiento de la aplicación o complemento (por ejemplo, si la aplicación o el complemento lo comunica con otras aplicaciones web fuera de Microsoft 365).
Al definir el ámbito de las pruebas de penetración, es fundamental incluir todos los sistemas o entornos conectados que puedan afectar a la seguridad del entorno dentro del ámbito.
Recomendaciones
Pruebas de penetración de aplicaciones web: se recomienda que las pruebas de penetración de aplicaciones web se realicen directamente en el entorno de producción en directo. Sin embargo, las pruebas de aplicaciones web se pueden realizar en un entorno de prueba/UAT (Pruebas de aceptación del usuario), siempre que el informe de pruebas de penetración confirme que el mismo código base se usa en producción en el momento de las pruebas.
Validación de segmentación: si se usan técnicas de segmentación para aislar entornos dentro del ámbito de otros, el informe de pruebas de penetración debe validar la eficacia de estas técnicas de segmentación. Esto garantiza que no se introducen vulnerabilidades a través del proceso de segmentación.
Requisitos de pruebas de penetración
Los informes de pruebas de penetración se revisarán para asegurarse de que no haya vulnerabilidades que cumplan los siguientes criterios de error automático descritos en los controles siguientes.
| Tipo de criterios | Controles de pruebas de penetración |
|---|---|
| Criterios generales | La aplicación web (autenticada y no autenticada) y tanto las pruebas internas (si procede) como las pruebas de penetración de la infraestructura externa deben tener lugar anualmente (cada 12 meses) y ser llevadas a cabo por una empresa independiente de confianza. |
| La corrección de las vulnerabilidades críticas y de alto riesgo identificadas debe completarse en el plazo de un mes a partir de la conclusión de las pruebas de penetración, o antes, en función del proceso de revisión documentado del ISV. | |
| Superficie externa completa (direcciones IP, direcciones URL, puntos de conexión de API, etc.) Debe incluirse en el ámbito de las pruebas de penetración y debe documentarse claramente en el informe de pruebas de penetración. | |
| A menos que el entorno se alinee con PaaS, las redes internas completas deben incluirse dentro del ámbito de las pruebas de penetración y deben documentarse claramente en el informe de pruebas de penetración. | |
| Las pruebas de penetración de aplicaciones web DEBEN incluir todas las clases de vulnerabilidad; por ejemplo, la versión más reciente de OWASP Top 10 o SANS Top 25 CWE. La recomendación es que esto se detalla en el informe de pruebas de penetración; de lo contrario, será difícil demostrarlo. | |
| La empresa de pruebas de penetración debe volver a probar las vulnerabilidades o vulnerabilidades críticas y de alto riesgo consideradas como errores automáticos y resaltarse claramente como fijas en el informe de pruebas de penetración. | |
| Criterios de error automático: | Presencia de un sistema operativo no compatible o biblioteca de JavaScript no admitida. |
| Presencia de cuentas administrativas predeterminadas, enumerables o adivinables. | |
| Presencia de riesgos de inyección de SQL. | |
| Presencia de scripting entre sitios. | |
| Presencia de vulnerabilidades de recorrido de directorio (ruta de acceso de archivo). | |
| Presencia de vulnerabilidades HTTP, por ejemplo, división de respuesta de encabezado, contrabando de solicitudes y ataques de desincronización. | |
| Presencia de divulgación de código fuente (incluido LFI). | |
| Cualquier puntuación crítica o alta tal como se define en las directrices de administración de revisiones de CVSS. | |
| Cualquier vulnerabilidad técnica significativa que se pueda aprovechar fácilmente para poner en peligro una gran cantidad de EUII o OUI. |
Importante
Los informes deben ser capaces de proporcionar la garantía suficiente de que todo lo detallado en la sección de requisitos de pruebas de penetración anterior se puede demostrar.
Requisitos y reglas de pruebas de penetración gratuitas
En el caso de los ISV que actualmente no realizan pruebas de penetración, Microsoft ofrece un servicio de pruebas de penetración gratuito como parte del proceso de certificación de Microsoft 365. Este servicio cubre hasta 12 días de pruebas manuales, con costos adicionales por los días requeridos más allá de esta responsabilidad del ISV.
Requisitos clave
Requisitos previos a la prueba: ISV debe enviar pruebas y recibir la aprobación del 50 % de los controles dentro del ámbito antes de programar la prueba de penetración.
Informe de prueba: este informe, junto con la certificación de Microsoft 365, se puede usar para demostrar a los clientes que su entorno es seguro.
Corrección de vulnerabilidades: los ISV son responsables de resolver las vulnerabilidades identificadas durante las pruebas antes de que se pueda conceder la certificación. Sin embargo, no se requiere un informe limpio, solo pruebas de confirmación de que las vulnerabilidades se han abordado adecuadamente.
Consideraciones adicionales
Una vez organizada una prueba de penetración, el ISV es responsable de cubrir las tarifas asociadas a la reprogramación o cancelaciones.
| Reprogramación de la escala temporal de tarifas | Proporción por pagar |
|---|---|
| Vuelva a programar la solicitud recibida más de 30 días antes de la fecha de inicio programada. | 0% por pagar |
| Vuelva a programar la solicitud recibida entre 8 y 30 días antes de la fecha de inicio programada. | 25% a pagar |
| Reprograme la solicitud recibida dentro de 2 a 7 días antes de la fecha de inicio programada con una fecha de re-reserva firme. | 50% a pagar |
| Vuelva a programar la solicitud recibida menos de 2 días antes de la fecha de inicio. | 100% por pagar |
| Escala temporal de la cuota de cancelación | Proporción por pagar |
|---|---|
| Solicitud de cancelación recibida más de 30 días antes de la fecha de inicio programada. | 25% a pagar |
| Solicitud de cancelación recibida de 8 a 30 días antes de la fecha de inicio programada. | 50% a pagar |
| Solicitud de cancelación recibida en un plazo de 7 días antes de la fecha de inicio programada. | 90% a pagar |
Seguridad operativa
Este dominio mide la alineación de los procesos de infraestructura e implementación compatibles de una aplicación con los procedimientos recomendados de seguridad.
Controles
| Familia de control | Controls |
|---|---|
| Aprendizaje de concienciación | Proporcione pruebas de que la organización proporciona formación de reconocimiento de seguridad establecida a los usuarios del sistema de información (incluidos administradores, ejecutivos sénior y contratistas) como parte de la formación inicial para nuevos usuarios o cuando sea necesario por los cambios del sistema de información. |
| Proporcione pruebas de una frecuencia de entrenamiento de reconocimiento definida por la organización. | |
| Proporcione pruebas de documentación y supervisión de las actividades individuales de reconocimiento de seguridad del sistema de información, a la vez que conserva registros de entrenamiento individuales a través de una frecuencia definida por la organización. | |
| Protección contra malware: antivirus | Proporcione pruebas de que la solución antimalware está activa y habilitada en todos los componentes del sistema muestreados y configurada para cumplir los criterios siguientes: |
| Si es antivirus, ese examen a través del acceso está habilitado y las firmas están actualizadas en un plazo de 1 día y bloquea automáticamente el malware o las alertas y las cuarentenas cuando se detecta malware. | |
| O bien, si EDR/NGAV (Endpoint Detection and Response/Next-Generation Antivirus) se realiza un examen periódico, se generan registros de auditoría y se mantienen actualizados continuamente y tienen capacidades de aprendizaje automático. | |
| Si EDR/NGAV bloquea el malware conocido e identifica y bloquea las nuevas variantes de malware en función de los comportamientos de macro, además de tener capacidades de lista segura completa. | |
| Protección contra malware: controles de aplicación | Proporcione pruebas demostrables de que existe una lista aprobada de software o aplicaciones con justificación empresarial y está actualizada. |
| Que cada aplicación se someta a un proceso de aprobación y cierre de sesión antes de su implementación | |
| Esa tecnología de control de aplicaciones está activa, habilitada y configurada en todos los componentes del sistema muestreados, como se documenta. | |
| Administración de revisiones: aplicación de revisiones y clasificación de riesgos | Proporcione documentación de directivas que rigen cómo se identifican y asignan nuevas vulnerabilidades de seguridad a una puntuación de riesgo. |
| Proporcione pruebas de cómo se identifican las nuevas vulnerabilidades de seguridad. | |
| Proporcione pruebas que demuestren que a todas las vulnerabilidades se les asigna una clasificación de riesgos una vez identificadas. | |
| Proporcione pruebas de que todos los componentes del sistema muestreados se están aplicando revisiones de acuerdo con los períodos de tiempo de aplicación de revisiones definidos por las organizaciones y los sistemas operativos y componentes de software no admitidos no están en uso. Cuando corresponda, debe incluir código base si se usa la tecnología sin servidor o PaaS, o tanto la infraestructura como la base de código si se usa IaaS. | |
| Directrices de período de aplicación de revisiones: Crítico – en 14 días, Alto – Dentro de 30 días, Medio – Dentro de 60 días. | |
| Examen de vulnerabilidades | Proporcione los informes trimestrales de examen de vulnerabilidades de la infraestructura y las aplicaciones web. El examen debe realizarse en toda la superficie pública (direcciones IP y direcciones URL) e intervalos IP internos. |
| Proporcione pruebas demostrables de que la corrección de las vulnerabilidades identificadas durante el examen de vulnerabilidades se aplica en consonancia con el período de tiempo de aplicación de revisiones documentado. | |
| Controles de seguridad de red (NSC) | Proporcione pruebas de que los controles de seguridad de red (NSC) están instalados en el límite del entorno dentro del ámbito e instalados entre la red perimetral y las redes internas. |
| Y si Hybrid, On-prem, IaaS también proporciona pruebas de que todo el acceso público finaliza en la red perimetral. | |
| Compruebe que todos los controles de seguridad de red (NSC) están configurados para quitar el tráfico no definido explícitamente dentro de la base de reglas y que las revisiones de reglas de controles de seguridad de red (NSC) se realizan al menos cada 6 meses. | |
| Cambiar control | Proporcione pruebas de que los cambios introducidos en los entornos de producción se implementan a través de solicitudes de cambio documentadas que contienen el impacto del cambio, detalles de los procedimientos de retroceso, pruebas que se llevarán a cabo, revisión y aprobación por parte del personal autorizado. |
| Proporcione pruebas de que existen entornos independientes para que: los entornos de desarrollo y prueba/ensayo exijan la separación de las tareas del entorno de producción, la separación de las tareas se aplica a través de controles de acceso, los datos de producción confidenciales no se usan en los entornos de desarrollo o prueba/ensayo. | |
| Protección del desarrollo o la implementación de software | Proporcione directivas y procedimientos que admitan el desarrollo seguro de software e incluyan estándares del sector o procedimientos recomendados para la codificación segura. Como Open Web Application Security Project (OWASP) Top 10 o SysAdmin, Audit, Network and Security (SANS) Top 25 Common Weakness Enumeration (CWE). |
| Proporcione pruebas de que los repositorios de código están protegidos para que: todos los cambios de código se sometan a un proceso de revisión y aprobación por parte de un segundo revisor antes de combinarse con la rama principal, haya controles de acceso adecuados, todo el acceso se aplique a través de la autenticación multifactor (MFA) | |
| Proporcione pruebas de que todas las versiones realizadas en los entornos de producción se revisan y aprueban antes de su implementación. | |
| Administración de cuentas | Proporcione pruebas de que las credenciales predeterminadas se deshabilitan, quitan o cambian en los componentes del sistema muestreados. |
| Proporcione evidencia de que se ha implementado un proceso para proteger (proteger) las cuentas de servicio y que este proceso se ha seguido. | |
| Proporcione pruebas de que: se emiten cuentas de usuario únicas a todos los usuarios, se siguen los principios de privilegios mínimos del usuario dentro del entorno, se aplica una directiva segura de contraseña/frase de contraseña u otras mitigaciones adecuadas, se implementa un proceso y se sigue al menos cada tres meses para deshabilitar o eliminar cuentas que no se usen en un plazo de tres meses. | |
| Valide que MFA está configurado para todas las conexiones de acceso remoto y todas las interfaces administrativas que no son de consola, incluido el acceso a los repositorios de código y las interfaces de administración en la nube. | |
| Registro de eventos de seguridad, revisión y alertas | Proporcione pruebas de que hay disponible inmediatamente un mínimo de 30 días de datos de registro de eventos de seguridad, con 90 días de registros de eventos de seguridad retenidos. |
| Proporcione pruebas de que los registros se revisan periódicamente y que los posibles eventos o anomalías de seguridad identificados durante el proceso de revisión se investigan y abordan. | |
| Proporcione pruebas de que las reglas de alertas están configuradas para que las alertas se desencadenen para la investigación de los siguientes eventos de seguridad cuando corresponda: creación o modificación de cuentas con privilegios, actividades o operaciones con privilegios o alto riesgo, eventos de malware, manipulación del registro de eventos, eventos IDPS /WAF. (si está configurado) | |
| Administración de riesgos de información | Proporcione pruebas de que se documenta y establece una directiva o proceso de administración de riesgos de seguridad de la información formal ratificada. |
| Proporcione pruebas de que se lleva a cabo una evaluación formal de riesgos de seguridad de la información en toda la empresa al menos anualmente. | |
| O para el análisis de riesgos dirigidos: se documenta y realiza un análisis de riesgos dirigido a cada 12 meses como mínimo para cada instancia en la que no se aplica un control tradicional o un procedimiento recomendado del sector, donde una limitación tecnológica o de diseño crea un riesgo de introducir una vulnerabilidad en el entorno o pone a los usuarios y los datos en riesgo, bajo sospecha o confirmación de compromiso. | |
| Valide que la evaluación de riesgos de seguridad de la información incluye componentes del sistema o recursos afectados, amenazas y vulnerabilidades o equivalentes, matrices de impacto y probabilidad o equivalente, la creación de un plan de tratamiento de riesgo o registro de riesgos. | |
| Proporcione pruebas de que dispone de procesos de administración de riesgos que evalúan y administran los riesgos asociados a proveedores y asociados empresariales, y que pueden identificar y evaluar los cambios y riesgos que podrían afectar al sistema de controles internos. | |
| Respuesta a incidentes de seguridad | Proporcione el plan o procedimiento de respuesta a incidentes de seguridad (IRP) ratificada. |
| Proporcione pruebas que describan cómo responde su organización a los incidentes, mostrando cómo se mantiene y que incluye detalles del equipo de respuesta a incidentes, incluida la información de contacto, un plan de comunicación interno durante el incidente y la comunicación externa a las partes pertinentes, como partes interesadas clave, marcas de pago y adquirentes, organismos reguladores (por ejemplo, 72 horas para el RGPD), supervisores, directores, clientes, así como pasos para actividades como la clasificación de incidentes, la contención, la mitigación, la recuperación y la vuelta a las operaciones empresariales normales en función del tipo de incidente | |
| Proporcione pruebas de que todos los miembros del equipo de respuesta a incidentes han recibido formación anual que les permite responder a incidentes. | |
| Proporcione pruebas de que la estrategia de respuesta a incidentes y la documentación complementaria se revisan y actualizan en función de las lecciones aprendidas de un ejercicio de la tabla superior, las lecciones aprendidas de responder a un incidente y los cambios de la organización. | |
| Plan de continuidad empresarial y plan de recuperación ante desastres | Proporcione pruebas de que la documentación existe y se mantiene, lo que describe el plan de continuidad empresarial. |
| Proporcione pruebas de que el plan de continuidad empresarial detalla el personal pertinente y sus roles y responsabilidades, incluidas: funciones empresariales con los requisitos y objetivos de contingencia asociados, procedimientos de copia de seguridad del sistema y de datos, configuración y programación/retención, prioridad de recuperación y objetivos de período de tiempo, un plan de contingencia que detalla las acciones, pasos y procedimientos que se deben seguir para devolver sistemas de información críticos, funciones empresariales y servicios a operar en caso de que se produzca un problema. interrupción inesperada y no programada, un proceso establecido que abarca la restauración completa final del sistema y volver al estado original. | |
| Proporcione pruebas de que la documentación existe, se mantiene y describe el plan de recuperación ante desastres e incluye como mínimo: personal y sus roles, responsabilidades y proceso de escalación, inventario de los sistemas de información que se usan para admitir funciones y servicios empresariales críticos, procedimientos y configuración de copia de seguridad de datos y sistemas, un plan de recuperación que detalla las acciones y procedimientos que se deben seguir para restaurar los datos y los sistemas de información críticos a funcionamiento. | |
| Proporcione pruebas de que el plan de continuidad empresarial y el plan de recuperación ante desastres se están revisando al menos cada 12 meses para asegurarse de que sigue siendo válido y eficaz durante situaciones adversas. | |
| Proporcione pruebas de que el plan de continuidad empresarial se actualiza en función de la revisión anual del plan, todo el personal pertinente que recibe formación sobre sus roles y responsabilidades asignadas en los planes de contingencia, los planes/s se prueban a través de ejercicios de continuidad empresarial o recuperación ante desastres, los resultados de las pruebas se documentan, incluidas las lecciones aprendidas del ejercicio o los cambios de la organización. |
Control de datos Seguridad y privacidad
Para garantizar la seguridad de los datos, los datos en tránsito entre el usuario de la aplicación, los servicios intermedios y los sistemas ISV deben cifrarse mediante la conexión TLS (seguridad de la capa de transporte). Como mínimo, se requiere TLS 1.2, con TLS 1.3 o superior fuertemente recomendado. Para obtener más información, consulte el Apéndice A.
Para las aplicaciones que recuperan o almacenan datos de Microsoft 365, es obligatorio implementar un esquema de cifrado de almacenamiento de datos. Esto debe alinearse con las especificaciones descritas en el Apéndice B.
Controles
| Familia de control | Controls |
|---|---|
| Datos en tránsito | Proporcione pruebas que validen que la configuración de TLS es TLS1.2 o posterior dentro de los requisitos de configuración del perfil TLS y que se mantiene y mantiene un inventario de claves y certificados de confianza. |
| Proporcionar evidencia muestra que la compresión TLS está deshabilitada para todos los servicios orientados al público que controlan solicitudes web para evitar la pérdida de información de relación de compresión Made Easy (CRIME), y TLS HSTS está habilitado y configurado en 180 días en todos los sitios. | |
| Datos en reposo | Proporcione pruebas de que los datos en reposo se cifran de acuerdo con los requisitos del perfil de cifrado, mediante algoritmos de cifrado como Advanced Encryption Standard (AES), RSA y Twofish con tamaños de clave de cifrado de 256 bits o superior. |
| Retención, copia de seguridad y eliminación de datos | Proporcione pruebas de que se ha establecido y documentado formalmente un período de retención de datos aprobado. |
| Proporcione pruebas de que los datos se conservan solo durante el período de retención definido, tal como se describe en el control anterior. | |
| Proporcione pruebas de que los procesos están en vigor para eliminar datos de forma segura después de su período de retención. | |
| Proporcione pruebas de que un sistema de copia de seguridad automatizado está implementado y configurado para realizar copias de seguridad a horas programadas. | |
| Proporcionar información de copia de seguridad de evidencia se prueba de acuerdo con el procedimiento de programación de copia de seguridad y se restaura periódicamente para confirmar la confiabilidad y la integridad de los datos. | |
| Proporcione pruebas de que se implementan controles de acceso y mecanismos de protección adecuados (es decir, copias de seguridad inmutables) para garantizar que las copias de seguridad o las instantáneas del sistema estén protegidas contra el acceso no autorizado y para garantizar la confidencialidad, integridad y disponibilidad de los datos de copia de seguridad. | |
| Administración del acceso a datos | Proporcione pruebas de que se mantiene una lista de usuarios con acceso a datos o claves de cifrado. La inclusión de la justificación empresarial para cada persona y la confirmación de que esta lista de usuarios se aprobó formalmente en función de los privilegios de acceso necesarios para su función de trabajo y los usuarios se configuran con los privilegios descritos en la aprobación. |
| Proporcione pruebas de que se mantiene una lista de todos los terceros con los que se comparten los datos y que se establecen acuerdos de uso compartido de datos con todos los terceros que consumen datos. | |
| Privacidad | ¿Su organización tiene un sistema de administración de información de privacidad (PIM) establecido, implementado y mantenido que mantiene el compromiso de liderazgo mediante una directiva u otra forma de documentación o sistema informatizado para cómo se mantienen los esfuerzos de administración de la información de privacidad para la confidencialidad y la integridad del sistema. Determina los roles, las responsabilidades y las autoridades de cada persona que mantiene el sistema, incluidos los procesadores y controladores pii. |
| Proporcionar pruebas de los procesos para comprobar que se está produciendo la minimización de PII, la desidentificación y eliminación de PII se realiza al final del período de procesamiento, se aplican controles para la transmisión de PII, incluida cualquier confidencialidad, existe un registro de transferencia de PII de un país o región a otro con consentimiento expreso para hacerlo. | |
| RGPD | Proporcione pruebas de que los interesados pueden generar SAR, de que el ISV es capaz de identificar todas las ubicaciones de los datos de los interesados al responder a una solicitud de SAR, de que hay un período de retención para las copias de seguridad que permite a los clientes que solicitan la eliminación de datos a través de SAR se quitan como copias de seguridad graduales durante un período (ciclo de vida de eliminaciones de copias de seguridad más antiguas o reescrituras). |
| Proporcione el aviso de privacidad que debe contener todos los elementos necesarios de la siguiente manera: los detalles de la organización (nombre, dirección y otra información de identificación personal), el tipo de datos personales que se procesan, cuánto tiempo se conservarán los datos personales, la legalidad del tratamiento de datos personales, los derechos de los interesados; incluyendo: derechos del interesado, derecho a ser informado, derecho de acceso por parte del interesado, derecho de supresión, derecho a restricción del procesamiento, derecho a portabilidad de datos, derecho a oposición, derechos en relación con la toma de decisiones automatizadas, incluida la generación de perfiles. | |
| HIPAA | Proporcione pruebas de que: existe una directiva para el control de HIPAA e HIPAA dentro de su organización para el personal, contratistas, proveedores, etc. Compruebe que nuestra organización garantiza la confidencialidad, integridad y disponibilidad de ePH. |
| Compruebe que: proporcione protección contra los usos o divulgaciones razonablemente previstos de dicha información que no están permitidos por la regla de privacidad, asegúrese de que su personal cumple la regla de seguridad. Proporcione un plan de copia de seguridad de datos y recuperación ante desastres en los puntos 164.308 (a)(7)(ii)(A) y 164.308 (a)(7)(ii)(B). |
Revisión opcional del marco de cumplimiento externo
Si su organización ya cumple con marcos de seguridad externos como ISO 27001, PCI DSS, FedRAMP o SOC 2 Tipo 2, puede optar por aprovechar estas certificaciones para satisfacer algunos de los controles de certificación de Microsoft 365. Los analistas intentarán alinear los marcos de seguridad externos existentes con los requisitos de certificación de Microsoft 365.
Sin embargo, si la documentación auxiliar no demuestra que los controles de certificación de Microsoft 365 se evaluaron explícitamente como parte de la auditoría o evaluación del marco externo, debe proporcionar pruebas adicionales para comprobar que estos controles están en vigor.
Requisitos de documentación
La documentación debe demostrar claramente que el entorno dentro del ámbito de la certificación de Microsoft 365 se incluye en el ámbito de los marcos de seguridad eternos. La validación de estos marcos se cumplirá mediante la aceptación de pruebas de certificaciones válidas emitidas por auditores de terceros acreditados y de confianza.
Estos auditores externos deben ser miembros de organismos internacionales de acreditación, como:
Estándares de certificación y conformidad para ISO 27001
Evaluadores de seguridad de calidad (QSA) para PCI DSS
Para obtener más información, consulte las directrices y estándares específicos para los marcos externos pertinentes para su certificación.
En la tabla siguiente se describen los marcos y la documentación necesarios aceptados por los analistas de certificación como parte del proceso de validación.
| Estándar | Requisitos |
|---|---|
| ISO 27001 | Se necesitará una versión pública de la Declaración de aplicabilidad (SOA) y una copia del certificado ISO 27001 emitido. El SOA resume su posición en cada uno de los 114 controles de seguridad de la información y se usará para identificar si existe alguna exclusión de controles que no se detallan satisfactoriamente en el certificado ISO 27001. Si esto no se puede determinar mediante la revisión de la versión pública del SOA, es posible que el analista necesite acceso al SOA completo si se usará ISO 27001 para validar algunos de los controles de seguridad de certificación de Microsoft 365. Además de validar el ámbito de las actividades de evaluación iso 27001, los analistas también confirmarán la validez de la empresa de auditoría como se ha descrito anteriormente. |
| PCI DSS | Se debe proporcionar un documento de atestación de cumplimiento (AOC) de nivel 1 válido que identifique claramente los componentes del sistema y la aplicación en el ámbito. No se aceptará una AOC de autoevaluación como prueba de los procedimientos recomendados de seguridad para reuniones. El AOC se usará para determinar cuál de los controles de especificación de certificación de Microsoft 365 se ha evaluado y confirmado como parte de la evaluación de PCI DSS. |
| SOC 2 | El informe SOC 2 (tipo II) debe ser actual (emitido en los últimos 15 meses y el período de tiempo declarado iniciado en los últimos 27 meses) para ser utilizado como prueba de conformidad con cualquiera de los controles de evaluación dentro de este marco de certificación de Microsoft 365. |
| FedRAMP | El Programa Federal de Administración de Riesgos y Autorización (FedRAMP) es un programa federal de todo el gobierno estadounidense establecido en 2011. Proporciona un enfoque estandarizado para la evaluación de la seguridad, la autorización y la supervisión continua de productos y servicios en la nube. |
| Marco | Consideraciones adicionales |
|---|---|
| ISO 27001 | Apéndice C: Colección de evidencias : Deltas para ISO 27001. |
| PCI DSS | Apéndice D: Colección de evidencias: deltas para PCI DSS. |
| SOC 2 | Apéndice E: Colección de evidencias: Deltas para SOC 2. |
Nota:
Aunque los estándares o marcos de seguridad externos se pueden enviar como pruebas auxiliares para cumplir ciertos controles de certificación de Microsoft 365, la obtención de la certificación de Microsoft 365 requiere una evaluación independiente. Lograr la certificación de Microsoft 365 no implica que la aplicación haya superado por completo las auditorías de estos marcos externos. La especificación de certificación de Microsoft 365 se centra en un subconjunto específico de controles derivados de estos marcos para proporcionar a Microsoft un mayor nivel de seguridad con respecto a la posición de seguridad de la aplicación.
Requisitos para usar marcos de cumplimiento externos
✓ El entorno en el ámbito y los procesos empresariales auxiliares deben incluirse dentro del ámbito de los marcos de cumplimiento de seguridad externos admitidos y deben indicarse claramente en la documentación proporcionada.
✓ Los marcos de cumplimiento de seguridad externos admitidos DEBEN estar actualizados, es decir, en los últimos 12 meses (o en un plazo de 15 meses si la reevaluación se está realizando actualmente y se pueden proporcionar pruebas).
✓ Los marcos de cumplimiento de seguridad externos compatibles deben ser llevados a cabo por una empresa acreditada independiente.