Introducción al marco de certificación de Microsoft 365
En este artículo se proporciona información detallada, incluida la lista de controles de seguridad de certificación de Microsoft 365 y compatibilidad con ISV y desarrolladores sometidos a la certificación de Microsoft 365.
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 sus atributos de cumplimiento de aplicaciones 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)
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. Revise los marcos de control de cumplimiento para ver si la aplicación es apta antes de iniciar la certificación. Para cualquier 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 ISV responden a un conjunto de preguntas sobre las prácticas de seguridad y control de datos de su aplicación. Las aplicaciones se pueden publicar en el Centro de partners de Microsoft y recibir filtros dedicados y incorrectos en Marketplace de Microsoft AppSource al finalizar.
Revisión de los criterios de control No es necesario 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. Algunos controles se clasifican como un "error difícil", lo que significa que la falta de estos controles de seguridad dará lugar a una evaluación errónea.
Importante
Período de tiempo de envío: En promedio, el proceso de evaluación debe tardar 30 días, siempre que los ISV puedan comprobar el estado de envío con frecuencia y responder a comentarios y solicitudes de pruebas complementarias de manera oportuna. Al iniciar el proceso de certificación, se permite un máximo de 60 días para completar la evaluación. Si todos los envíos no se han completado dentro del período de tiempo de 60 días, el envío se emitirá un error y el proceso debe iniciarse de nuevo. Estos resultados no se harán públicos.
Ámbito de certificación
El entorno en el ámbito admite la entrega del código de aplicación o complemento y admite cualquier sistema back-end con el que pueda comunicarse la aplicación o el complemento. Los entornos adicionales conectados al entorno dentro del ámbito también se incluirán en el ámbito, a menos que haya una segmentación adecuada y los entornos conectados no puedan afectar a la seguridad del entorno dentro del ámbito.
Cualquier entorno de recuperación ante desastres independiente también tendrá que incluirse en el entorno dentro del ámbito, ya que estos entornos serían necesarios para cumplir el servicio en caso de que algo suceda en el entorno principal. Los entornos de copia de seguridad remota también tendrán que incluirse, ya que estos entornos pueden almacenar datos de Microsoft y, por lo tanto, deben existir controles de seguridad adecuados.
El término componentes del sistema en el ámbito hace referencia a TODOS los dispositivos y sistemas que se usan en el entorno definido en el ámbito. Los componentes dentro del ámbito incluyen, pero no se limitan a:
- Aplicaciones web
- Servidores (físicos o virtuales que pueden ser locales o en la nube)
- Controles de seguridad de red (NSC), como firewalls
- Modificadores
- Equilibradores de carga
- Infraestructura virtual
- Portales de administración web del proveedor de nube
- Recursos en la nube (Virtual Machines, App Service, cuentas de almacenamiento, instancias EC2, etc.)
Importante
Los componentes del sistema accesibles públicamente son susceptibles a ataques de actores de amenazas externos y, por lo tanto, corren un riesgo mucho mayor. Normalmente, estos sistemas se segmentarían lejos de otros componentes internos del sistema mediante un control de seguridad de red (NSC) que crea una zona desmilitarizada (DMZ). La intención es que la red perimetral sea menos confiable que la red interna y una seguridad adicional ayudaría a proteger aún más los sistemas internos y los datos en caso de que los sistemas accesibles al público se vean comprometidos. Idealmente, se usaría una red perimetral, pero esto no es factible o incluso necesario en algunos escenarios de implementación.
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.
El apéndice C proporciona detalles sobre qué controles de seguridad probablemente serán aplicables en función de los siguientes tipos de implementación y en función de si la aplicación filtra los datos de Microsoft 365:
- ISV hospedado
- IaaS Hosted
- Hospedado sin servidor o PaaS
- Hospedado híbrido
- Hospedado compartido
Cuando se implementa IaaS o PaaS, se deben proporcionar pruebas que validen la alineación del entorno con estos tipos de implementación.
Muestreo
Las solicitudes de pruebas en apoyo de la evaluación de certificación deben basarse en una muestra de los componentes del sistema en el ámbito en consideración de los diferentes sistemas operativos, la función principal del dispositivo, los distintos tipos de dispositivos (es decir, servidores, NSC, enrutadores, etc.) y la ubicación. Se seleccionará un ejemplo adecuado al principio del proceso de certificación. La tabla siguiente debe usarse como guía en la que el muestreo se determinará en función de los factores detallados anteriormente:
| Tamaño de población | Muestra |
|---|---|
| <=5 | 1 |
| >5 & <10= | 2 |
| >10 & <=30 | 3 |
| >30 | 4 |
Nota:
Si se identifican discrepancias entre los dispositivos incluidos en el ejemplo inicial, el tamaño de la muestra puede aumentarse durante la evaluación.
Proceso de certificación de un extremo a otro
Para comenzar la certificación de Microsoft 365:
Vaya al Centro de partners y complete la atestación del publicador. Si el envío tiene más de tres meses de antigüedad, vuelva a enviar para su revisión y validación.
En el Centro de partners, seleccione "Iniciar certificación" para comenzar el envío inicial del documento. Esto ayudará a los analistas de certificación a determinar qué está en el ámbito de la evaluación en función de la arquitectura de la aplicación y cómo controla los datos de Microsoft.
Sugerencia
Siga la guía paso a paso para obtener la aplicación Microsoft 365 Certified.
El proceso de certificación se lleva a cabo en dos fases, como se describe a continuación:
El envío inicial de documentos ayuda al analista a comprender la aplicación, los flujos de datos, definir el entorno dentro del ámbito, identificar qué controles de seguridad son aplicables y determinar los componentes del sistema de los que se deben recopilar pruebas. El ISV debe proporcionar información solicitada para ayudar al analista de certificación a completar esta fase del proceso, que es aproximadamente el 5 % del proceso general.
La revisión completa de pruebas es el proceso por el que el ISV envía artefactos de evidencia que muestran cómo el entorno dentro del ámbito está cumpliendo los controles de seguridad. Habrá varias interacciones entre el ISV y el analista durante esta fase de auditoría, que es el resto del proceso.
Evaluación
Una vez aceptado el envío inicial del documento, el conjunto de controles de seguridad se mostrará automáticamente en el portal. Los ISV deben proporcionar pruebas para cada control que demuestre que el control está en vigor y tener 60 días para enviar todas las pruebas. Un analista revisará las pruebas y aprobará el control o solicitará pruebas nuevas o adicionales.
Certificación
Una vez que un analista valida un envío, se notifica a los ISV la decisión de certificación. Las aplicaciones premiadas con una certificación recibirán un distintivo en su aplicación dentro de AppSource y páginas de documentos de Microsoft dedicadas con informes detallados de sus atributos de seguridad y cumplimiento.
Revisión y recertificación
Las aplicaciones certificadas de Microsoft 365 deben pasar por la recertificación anualmente. Esto requerirá la revalidación de los controles dentro del ámbito en el entorno actual dentro del ámbito. Este proceso puede comenzar hasta 90 días antes de la expiración de la certificación. Las certificaciones existentes no expirarán durante el período de recertificación. La recertificación en todos los programas expira en el aniversario de un año de la certificación de Microsoft 365.
Si la certificación no se renueva antes de la fecha de expiración, se revocará el estado de certificación de las aplicaciones. Todas las etiquetas, iconos y marcas de certificación asociadas se quitarán de la aplicación, y se prohibirá a los ISV anunciar la aplicación como Microsoft 365 Certified.
Si una aplicación experimenta cambios significativos fuera del período de tiempo de envío de recertificación, se le pedirá que notifique al Programa de cumplimiento de aplicaciones de Microsoft cualquier actualización.
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 proporcionadas para determinar si se han cumplido todos los controles para la certificación de Microsoft 365.
Para reducir la cantidad de tiempo necesario para completar la evaluación, se debe proporcionar cualquiera o toda la documentación detallada en el envío de documentación inicial con antelación.
Los analistas de certificación revisarán primero las pruebas proporcionadas en el envío de documentación inicial y la información de atestación del publicador para identificar las líneas de investigación adecuadas, el tamaño del muestreo y la necesidad de obtener más pruebas, tal como se ha detallado anteriormente. Los analistas de certificación analizarán toda la información recopilada para extraer conclusiones sobre cómo y si cumple los controles de esta especificación de certificación de Microsoft 365.
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 elementos de esta especificación incluyen algunos criterios de error automático:
- Los permisos de API no siguen el principio de privilegios mínimos (PoLP).
- No hay ningún informe de pruebas de penetración cuando sea necesario.
- No hay defensas antimalware.
- Multi-Factor Authentication no se usa para proteger el acceso administrativo.
- Sin procesos de aplicación de revisiones.
- No hay un aviso de privacidad de RGPD adecuado.
Seguridad de la aplicación
El dominio de seguridad de la aplicación se centra en tres áreas:
- Validación de permisos de GraphAPI
- Comprobaciones de conectividad externa
- Pruebas de penetración
Validación de permisos de GraphAPI
La validación de permisos de GraphAPI se lleva a cabo para validar que la aplicación o el complemento no solicita permisos excesivamente permisivos. Esto se lleva a cabo comprobando manualmente qué permisos se solicitan. Los analistas de certificación harán referencia cruzada a estas comprobaciones con el envío de atestación del publicador y evaluarán el nivel de acceso que se solicita para asegurarse de que se cumplen las prácticas de "privilegios mínimos". Cuando los analistas de certificación creen que no se cumplen estas prácticas de "privilegios mínimos", los analistas de certificación tendrán una discusión abierta con el ISV para validar la justificación empresarial de los permisos que se solicitan. Cualquier discrepancia con el envío de atestación del publicador encontrada durante esta revisión deberá corregirse.
Comprobaciones de conectividad externa
Como parte de la evaluación, se realizará un ligero recorrido por la funcionalidad de las aplicaciones para identificar las conexiones que se realizan fuera de Microsoft 365. Las conexiones que no se identifican como microsoft o conexiones directas al servicio se marcarán y tratarán durante la evaluación.
Pruebas de penetración
Una revisión adecuada de los riesgos asociados con la aplicación o el complemento y el entorno auxiliar es esencial para proporcionar a los clientes garantías en la seguridad de la aplicación o complemento. Las pruebas de seguridad de aplicaciones en forma de pruebas de penetración deben realizarse si la aplicación tiene conectividad con cualquier servicio no publicado por Microsoft. Si una vez implementada la aplicación funciona de forma independiente y solo tiene acceso al servicio Microsoft, como GraphAPI, no es necesario realizar pruebas de penetración. Las pruebas de penetración siguen siendo necesarias si el entorno dentro del ámbito está hospedado en Azure.
Ámbito de pruebas de penetración
Para las pruebas de penetración de infraestructura interna y externa, todas las actividades de pruebas de penetración deben realizarse en el entorno de producción en directo que admita la implementación de la aplicación o el complemento (por ejemplo, donde se hospeda el código de aplicación o complemento, que normalmente será el recurso dentro del archivo de manifiesto) junto con los entornos adicionales que admiten el funcionamiento de la aplicación o complemento (por ejemplo, si la aplicación o el complemento se comunica con otras aplicaciones web fuera de Microsoft 365). Al definir el ámbito de las pruebas de penetración, es necesario tener cuidado para asegurarse de que todos los sistemas o entornos "conectados" que puedan afectar a la seguridad del entorno dentro del ámbito también se incluyan dentro de todas las actividades de pruebas de penetración.
Se recomienda realizar pruebas de penetración de aplicaciones web en el entorno de producción en directo. Sin embargo, sería aceptable realizar pruebas solo de la aplicación web mediante un entorno de prueba/UAT, siempre que se confirme en el informe de pruebas de penetración que el mismo código base funcionaba exactamente dentro del entorno de prueba/UAT en el momento de las pruebas.
Cuando se usan técnicas para segmentar los entornos dentro del ámbito de otros entornos, las actividades de pruebas de penetración DEBEN validar la eficacia de dichas técnicas de segmentación. Esto debe detallarse en el informe de pruebas de penetración.
Nota:
Las pruebas de penetración internas deben realizarse a menos que el entorno de hospedaje solo se clasque como PaaS.
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 participan en pruebas de penetración, las pruebas de penetración se pueden realizar de forma gratuita para la certificación de Microsoft 365. Microsoft organizará y cubrirá el costo de una prueba de penetración durante un máximo de 12 días de pruebas manuales. Los costos de las pruebas de penetración se calculan en función del número de días necesarios para probar el entorno dentro del ámbito. Cualquier gasto que supere los 12 días de prueba será responsabilidad del ISV.
- Los ISV deberán presentar pruebas y recibir la aprobación del 50 % de los controles en el ámbito antes de que se realice la prueba de penetración. Para empezar, rellene el envío inicial del documento y elija incluir pruebas de penetración como parte de la evaluación. Se le contactará para establecer el ámbito y programar la prueba de penetración cuando haya completado el 50 % de los controles.
- El informe emitido una vez completada la prueba de lápiz se proporcionará al ISV una vez que haya completado la certificación. Este informe junto con la certificación de Microsoft 365 se puede usar para mostrar a los clientes potenciales que su entorno es seguro.
- Los ISV también serán responsables de demostrar que las vulnerabilidades identificadas en la prueba de penetración se han corregido antes de que se otorgue una certificación, pero no es necesario generar un informe limpio.
Una vez organizada una prueba de penetración, el ISV es responsable de las tarifas asociadas a la reprogramación y cancelaciones de la siguiente manera:
| 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 |
| Vuelva a programar la solicitud recibida en un plazo de 2 a 7 días antes de la fecha de inicio programada con una fecha de nueva reserva de empresa. | 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 están siendo revisados en línea 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 las correcciones de vulnerabilidades identificadas durante el examen de vulnerabilidades se aplican de acuerdo con el período de tiempo de revisión 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
Los datos en tránsito entre el usuario de la aplicación, los servicios intermedios y los sistemas de ISV deberán protegerse mediante cifrado a través de una conexión TLS que admita un mínimo de TLS v1.1. (Se recomienda TLS v1.2 y versiones posteriores). Consulteel Apéndice A.
Cuando la aplicación recupere y almacene datos de Microsoft 365, deberá implementar un esquema de cifrado de almacenamiento de datos que siga la especificación definida 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: detalles oranizationales (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 de marcos de cumplimiento externo
Aunque no es necesario, si actualmente cumple con iso 27001, PCI DSS, FedRAMP o SOC2, puede optar por usar 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 el marco de certificación de Microsoft 365. Sin embargo, si la documentación auxiliar no puede proporcionar garantías de que los controles de certificación de Microsoft 365 se evaluaron como parte de la auditoría o evaluación de marcos de seguridad externos, deberá proporcionar pruebas adicionales de que dichos controles están en vigor.
La documentación debe demostrar adecuadamente que el entorno dentro del ámbito de la certificación de Microsoft 365 se incluyó en el ámbito de estos marcos de seguridad externos. La validación de estos marcos de seguridad se cumplirá aceptando pruebas de certificaciones válidas realizadas por empresas externas de confianza. Estas empresas de confianza deben ser miembros de organismos internacionales de acreditación para los programas de cumplimiento pertinentes. Consulte Iso Certification and Conformity Standards for ISO 27001 and Qualified Security Assessors (QSA) for PCI DSS(Estándares de certificación y conformidad iso 27001 y evaluadores de seguridad calificados (QSA) para PCI DSS.
En la tabla siguiente se resaltan los marcos externos y la documentación que requieren los analistas de certificación como parte de este 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 marcos o estándares de seguridad externos mencionados anteriormente se pueden enviar como prueba para cumplir algunos de los controles de certificación de Microsoft 365, pasar la certificación de Microsoft 365 no significa que una aplicación supere correctamente una auditoría con esos estándares o marcos. La especificación de certificación de Microsoft 365 es solo un pequeño subconjunto de esos estándares o marcos de seguridad que permite a Microsoft obtener un nivel de garantía en referencia a su posición de seguridad.
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.