Apéndice y glosario de documentación de cumplimiento de aplicaciones de Microsoft 365
Apéndice A
Requisitos de configuración del perfil TLS
Todo el tráfico de red, ya sea dentro de una red virtual, un servicio en la nube o un centro de datos, debe protegerse con un mínimo de TLS v1.1 (se recomienda TLS v1.2+) u otro protocolo aplicable. Las excepciones a este requisito son:
- Redirección de HTTP a HTTPS. La aplicación puede responder a través de HTTP para redirigir los clientes a HTTPS, pero la respuesta no debe contener datos confidenciales (cookies, encabezados, contenido). No se permiten otras respuestas HTTP que no sean redireccionamientos a HTTPS y que respondan a sondeos de estado. Véalo a continuación.
- Sondeos de estado. La aplicación solo puede responder a sondeos de estado a través de HTTP si los sondeos de estado HTTPS no son compatibles con la entidad de comprobación.
- Acceso al certificado. El acceso a los puntos de conexión CRL, OCSP y AIA con fines de validación y revocación de certificados se permite a través de HTTP.
- Comunicaciones locales. La aplicación puede usar HTTP (u otros protocolos no protegidos) para las comunicaciones que no dejan el sistema operativo, por ejemplo, conectarse a un punto de conexión de servidor web expuesto en localhost.
La compresión TLS debe estar deshabilitada.
Apéndice B
Requisitos de configuración del perfil de cifrado
Solo se permiten primitivos y parámetros criptográficos como se indica a continuación:
Criptografía simétrica
Cifrado
✓ Solo se permiten AES, BitLocker, Blowfish o TDES. Se permite cualquiera de las longitudes de clave admitidas >=128 (128 bits, 192 bits y 256 bits) y se puede usar (se recomiendan claves de 256 bits).
✓ Solo se permite el modo CBC. Cada operación de cifrado debe usar un vector de inicialización (IV) nuevo y generado aleatoriamente.
✓ No se permite el uso de cifrados de secuencias, como RC4, IS .
Funciones hash
✓ Todo el código nuevo debe usar SHA-256, SHA-384 o SHA-512 (denominado colectivamente SHA-2). La salida se puede truncar a no menos de 128 bits
✓ SHA-1 solo se puede usar por motivos de compatibilidad.
✓ No se permite el uso de MD5, MD4, MD2 y otras funciones hash, ni siquiera para aplicaciones no criptográficas.
Autenticación de mensajes
✓ Todo el nuevo código DEBE usar HMAC con una de las funciones hash aprobadas. La salida de HMAC se puede truncar a no menos de 128 bits.
✓ HMAC-SHA1 solo se puede usar por motivos de compatibilidad.
✓ La clave HMAC debe tener al menos 128 bits. Se recomiendan claves de 256 bits.
Algoritmos asimétricos
Cifrado
✓ Se permite RSA. La clave debe tener al menos 2048 bits y se debe usar el relleno de OAEP. El uso del relleno PKCS solo se permite por motivos de compatibilidad.
Firmas
✓ Se permite RSA. La clave DEBE tener al menos 2048 bits y se debe usar el relleno PSS. El uso del relleno PKCS solo se permite por motivos de compatibilidad.
Se permite ✓ECDSA. La clave DEBE tener al menos 256 bits. Se debe usar la curva NIST P-256, P-384 o P-521.
Intercambio de claves
✓ ECDH está permitido. La clave DEBE tener al menos 256 bits. Se debe usar la curva NIST P-256, P-384 o P-521.
✓ ECDH está permitido. La clave DEBE tener al menos 256 bits. Se debe usar la curva NIST P-256, P-384 o P-521.
Apéndice C
Colección de evidencias: Delta para ISO 27001
Cuando ya haya alcanzado ISO27001 cumplimiento, las siguientes diferencias (brechas) no cubiertas totalmente por ISO 27001 deberán revisarse como mínimo como parte de esta certificación de Microsoft 365.
Nota:
Como parte de la evaluación de certificación de Microsoft 365, el analista de certificación determinará si alguno de los controles ISO 27001 asignados no se incluyó como parte de la evaluación ISO 27001 y también puede decidir si se incluyeron los controles de ejemplo que se han incluido para proporcionar mayor seguridad. Los requisitos que falten en la norma ISO 27001 deberán incluirse dentro de las actividades de evaluación de la certificación de Microsoft 365.
Protección contra malware: antivirus
Si la protección contra malware está en vigor mediante el control de aplicaciones y se atestigua en el informe ISO 27001, no es necesario realizar ninguna investigación adicional. Si no hay ningún control de aplicación, los analistas de certificación deberán identificar y evaluar las pruebas de los mecanismos de control de aplicaciones para evitar la detonación de malware dentro del entorno. Esto requerirá que:
Demostrar que el software antivirus se ejecuta en todos los componentes del sistema muestreados.
Demostrar que el antivirus está configurado en todos los componentes del sistema muestreados para bloquear automáticamente el malware, poner en cuarentena & alerta o alertar.
El software antivirus debe configurarse para registrar todas las actividades.
Administración de revisiones: aplicación de revisiones
Como las auditorías ISO 27001 no evalúan específicamente esta categoría, esto requerirá que:
- Los componentes de software y los sistemas operativos que ya no son compatibles con el proveedor no deben usarse dentro del entorno. Las directivas auxiliares deben estar implementadas para asegurarse de que los componentes de software o sistemas operativos no admitidos se quitarán del entorno y un proceso para identificar cuándo los componentes de software van al final de la vida útil deben estar en su lugar.
Detección de vulnerabilidades
Como las auditorías ISO 27001 no evalúan específicamente esta categoría, esto requerirá que:
Demostrar que se realiza un examen trimestral de vulnerabilidades internas y externas.
Confirme que la documentación auxiliar está en su lugar para la corrección de vulnerabilidades en función de la clasificación de riesgos y en consonancia con la especificación de la siguiente manera:
✓ Corrija todos los problemas de riesgo críticos y altos en línea con la clasificación de riesgos para el análisis interno.
✓ Corrija todos los problemas de riesgo crítico, alto y medio en línea con la clasificación de riesgos para el análisis externo.
✓ Demostrar que la corrección se realiza en línea con la directiva de corrección de vulnerabilidades documentada.
Firewall: firewalls (o tecnologías equivalentes)
Como las auditorías ISO 27001 no evalúan específicamente esta categoría, esto requerirá que:
Demostrar que los firewalls están instalados en el límite del entorno dentro del ámbito.
Demostrar que los firewalls están instalados entre la red perimetral y las redes de confianza.
Demostrar que todo el acceso público finaliza en la red perimetral.
Demostrar que las credenciales administrativas predeterminadas se cambian antes de la instalación en el entorno activo.
Demostrar que todo el tráfico permitido a través de los firewalls pasa por un proceso de autorización, lo que da como resultado la documentación de todo el tráfico con una justificación empresarial.
Demostrar que todos los firewalls están configurados para quitar el tráfico no definido explícitamente.
Demostrar que los firewalls solo admiten criptografía segura en todas las interfaces administrativas que no son de consola.
Demostrar que las interfaces administrativas que no son de consola del firewall expuestas a Internet admiten MFA.
Demostrar que las revisiones de reglas de firewall se realizan al menos cada 6 meses
Firewall: firewalls de aplicaciones web (WAF)
Se proporcionará crédito adicional si se implementa un WAF para ayudar a protegerse frente a la infinidad de amenazas y vulnerabilidades de aplicaciones web a las que se puede exponer la aplicación. Cuando haya un WAF o similar, esto requerirá que:
Demostrar que WAF está configurado en modo de defensa activo o supervisando más con las alertas.
Demostrar que WAF está configurado para admitir la descarga de SSL.
Se configura según el conjunto de reglas principal de OWASP (3.0 o 3.1) para protegerse frente a la mayoría de los siguientes tipos de ataque:
✓ Problemas de protocolo y codificación.
✓ Inyección de encabezados, contrabando de solicitudes y división de respuestas.
✓ Ataques de recorrido de archivos y rutas de acceso.
✓ Ataques de inclusión remota de archivos (RFI).
✓ Ataques de ejecución remota de código.
✓ Ataques por inyección de PHP.
✓ Ataques de scripting entre sitios.
✓ Ataques por inyección de CÓDIGO SQL.
✓ Ataques de fijación de sesión.
Cambiar control
Dado que las auditorías ISO 27001 no evalúan específicamente algunos elementos de los procesos de solicitud de cambios, esto requerirá que:
- Demostrar que las solicitudes de cambio tienen los siguientes detalles:
✓ Impacto documentado.
✓ Detalles de qué pruebas de funcionalidad se van a realizar.
✓ Detalles de los procedimientos de retroceso.
Demostrar que las pruebas de funcionalidad se realizan una vez completados los cambios.
Demostrar que las solicitudes de cambio se cierran después de realizar pruebas de funcionalidad.
Administración de cuentas
Dado que las auditorías ISO 27001 no evalúan específicamente algunos elementos de los procesos de administración de cuentas, esto requerirá que:
- Demostrar cómo se implementan las ✓s para mitigar los ataques de reproducción (por ejemplo, MFA, Kerberos).
- Muestra cómo se deshabilitan o eliminan las cuentas que no se han usado en 3 meses.
- ✓u otras mitigaciones adecuadas deben configurarse para proteger las credenciales de usuario. La siguiente directiva de contraseña mínima debe usarse como guía:
✓ Longitud mínima de contraseña de 8 caracteres.
✓ Umbral de bloqueo de cuenta de no más de 10 intentos.
✓ Historial de contraseñas de un mínimo de cinco contraseñas.
✓ Aplicación del uso de contraseñas seguras.
Demostrar que MFA está configurado para todas las soluciones de acceso remoto.
Demostrar que el cifrado seguro está configurado en todas las soluciones de acceso remoto.
Cuando la administración de DNS público está fuera del entorno dentro del ámbito, todas las cuentas de usuario que puedan realizar modificaciones de DNS deben configurarse para usar MFA.
Detección y prevención de intrusiones (OPCIONAL)
Dado que las auditorías ISO 27001 no evalúan específicamente algunos elementos de los procesos de Servicios de detección y prevención de intrusiones (IDPS), esto requerirá que:
IDPS DEBE implementarse en el perímetro del entorno auxiliar.
Las firmas IDPS DEBEN mantenerse actualizadas en el último día.
EL IDPS DEBE configurarse para la inspección de TLS.
IDPS DEBE configurarse para TODO el tráfico entrante y saliente.
IDPS DEBE configurarse para las alertas.
Registro de eventos
Como las auditorías ISO 27001 no evalúan específicamente algunos elementos de los procesos de registro de eventos de seguridad, esto requerirá que:
Demostrar que los sistemas accesibles públicamente están registrando en una solución de registro centralizada que no está dentro de la red perimetral.
Demostrar cómo un mínimo de 30 días de datos de registro está disponible inmediatamente, con 90 días retenidos.
Revisión (registro de datos)
Dado que las auditorías ISO 27001 no evalúan específicamente algunos elementos de esta categoría, esto requerirá que:
- Demostrar cómo se realizan las revisiones de registros diarias y cómo se identifican las excepciones y anomalías, lo que muestra cómo se controlan.
Alertas
Dado que las auditorías ISO 27001 no evalúan específicamente algunos elementos de esta categoría, esto requerirá que:
Demostrar cómo se configuran los eventos de seguridad para desencadenar alertas para la evaluación de prioridades inmediata.
Demostrar cómo el personal está disponible 24/7 para responder a las alertas de seguridad.
Administración de riesgos
Dado que las auditorías ISO 27001 no evalúan específicamente algunos elementos de los procesos de evaluación de riesgos, esto requerirá que:
- Demostrar que se establece un proceso formal de administración de riesgos.
Respuesta a incidentes
Dado que las auditorías ISO 27001 no evalúan específicamente algunos elementos de las directivas y procesos de respuesta a incidentes, esto requerirá que:
- Demostrar que el plan o procedimiento de respuesta a incidentes incluye:
✓ Procedimientos de respuesta específicos para los modelos de amenazas esperados.
✓ Capacidades de control de incidentes que se alinean con NIST Cybersecurity Framework (Identificar, Proteger, Detectar, Responder, Recuperar).
✓ El IRP cubre los sistemas en el ámbito.
✓ Entrenamiento anual para el equipo de respuesta a incidentes.
Apéndice D
Colección de evidencias: deltas para PCI DSS
Cuando ya haya alcanzado el cumplimiento de PCI DSS, las siguientes diferencias (brechas) no cubiertas totalmente por PCI DSS tendrán que revisarse, como mínimo, como parte de esta certificación de Microsoft 365.
Nota:
Como parte de la evaluación de certificación de Microsoft 365, el analista de certificación determinará si alguno de los controles PCI DSS asignados no se incluyó como parte de la evaluación de PCI DSS y también puede decidir mostrar los controles que se han encontrado que se han incluido para proporcionar una mayor garantía. Los requisitos que falten en PCI DSS deberán incluirse en las actividades de evaluación de la certificación de Microsoft 365.
Protección contra malware: control de aplicaciones
Si la protección contra malware está en vigor mediante el uso de antivirus y se atestigua en el informe de PCI DSS, no es necesario realizar ninguna investigación adicional. Si no existe ningún antivirus, los analistas de certificación deberán identificar y evaluar las pruebas de los mecanismos de control de aplicaciones para evitar la detonación de malware dentro del entorno. Esto requerirá que:
Muestre cómo se lleva a cabo la aprobación de la aplicación y confirme que se ha completado.
Demostrar que existe una lista completa de aplicaciones aprobadas con justificación empresarial.
Proporcione o muestre documentación complementaria que detalla cómo se configura el software de control de aplicaciones para cumplir los mecanismos de control de aplicaciones específicos (es decir, la lista de permitidos, la firma de código, etc.).
Demostrar que en todos los componentes del sistema muestreados, el control de la aplicación se configura como se documenta.
Administración de revisiones: clasificación de riesgos
Como las auditorías de PCI DSS no evalúan específicamente esta categoría, esto requerirá que:
- Demostrar cómo se realiza la clasificación de riesgos de vulnerabilidades.
Detección de vulnerabilidades
Como las auditorías de PCI DSS no evalúan específicamente esta categoría, esto requerirá que:
- Demostrar que la corrección se realiza en línea con la directiva de corrección de vulnerabilidades documentada.
Firewall: firewalls (o tecnologías equivalentes)
Como las auditorías de PCI DSS no evalúan específicamente esta categoría, esto requerirá que:
Demostrar que los firewalls solo admiten criptografía segura en todas las interfaces administrativas que no son de consola.
Demostrar que las interfaces administrativas que no son de consola del firewall expuestas a Internet admiten MFA.
Se proporcionará crédito adicional si se implementa un Web Application Firewall (WAF) para ayudar a protegerse frente a la infinidad de amenazas y vulnerabilidades de aplicaciones web a las que se puede exponer la aplicación. Cuando haya un WAF o similar, esto requerirá que:
Demostrar que WAF está configurado en modo de defensa activo o supervisando más con las alertas.
Demostrar que WAF está configurado para admitir la descarga de SSL.
Se configura según el conjunto de reglas principal de OWASP (3.0 o 3.1) para protegerse frente a la mayoría de los siguientes tipos de ataque:
✓ Problemas de protocolo y codificación.
✓ Inyección de encabezados, contrabando de solicitudes y división de respuestas.
✓ Ataques de recorrido de archivos y rutas de acceso.
✓ Ataques de inclusión remota de archivos (RFI).
✓ Ataques de ejecución remota de código.
✓ Ataques por inyección de PHP.
✓ Ataques de scripting entre sitios.
✓ Ataques por inyección de CÓDIGO SQL.
✓ Ataques de fijación de sesión.
Cambiar control
Como las auditorías de PCI DSS no evalúan específicamente algunos elementos de los procesos de solicitud de cambios, esto requerirá que:
Demostrar que las solicitudes de cambio se generan antes de realizarse en entornos de producción.
Demostrar que los cambios están autorizados antes de entrar en producción.
Demostrar que las pruebas de funcionalidad se realizan una vez completados los cambios.
Demostrar que las solicitudes de cambio se cierran después de realizar pruebas de funcionalidad.
Protección del desarrollo o la implementación de software
Como las auditorías de PCI DSS no acceden específicamente a algunos elementos de procesos de implementación y desarrollo de software seguros; esto le requerirá lo siguiente:
Los repositorios de código deben protegerse mediante MFA.
Deben existir controles de acceso adecuados para proteger los repositorios de código frente a modificaciones de código malintencionadas.
Administración de cuentas
Dado que las auditorías de PCI DSS no evalúan específicamente algunos elementos de los procesos de administración de cuentas, esto requerirá que:
Demostrar cómo se implementan los mecanismos de autorización para mitigar los ataques de reproducción (por ejemplo, MFA, Kerberos).
Las directivas de contraseña segura u otras mitigaciones adecuadas deben configurarse para proteger las credenciales de usuario. La siguiente directiva de contraseña mínima debe usarse como guía:
✓ Longitud mínima de contraseña de 8 caracteres.
✓ Umbral de bloqueo de cuenta de no más de 10 intentos.
✓ Historial de contraseñas de un mínimo de cinco contraseñas.
✓ Aplicación del uso de contraseñas seguras.
Demostrar que el cifrado seguro está configurado en todas las soluciones de acceso remoto.
Cuando la administración de DNS público está fuera del entorno dentro del ámbito, todas las cuentas de usuario que puedan realizar modificaciones de DNS deben configurarse para usar MFA.
Detección y prevención de intrusiones (OPCIONAL)
Dado que las auditorías de PCI DSS no evalúan específicamente algunos elementos de los procesos de Servicios de detección y prevención de intrusiones (IDPS), esto requerirá que:
EL IDPS DEBE configurarse para la inspección de TLS.
IDPS DEBE configurarse para TODO el tráfico entrante y saliente.
Administración de riesgos
Dado que las auditorías de PCI DSS no evalúan específicamente algunos elementos de los procesos de evaluación de riesgos, esto requerirá que:
- Demostrar que la evaluación de riesgos incluye matrices de impacto y probabilidad.
Respuesta a incidentes
Como las auditorías de PCI DSS no evalúan específicamente algunos elementos de las directivas y procesos de respuesta a incidentes, esto requerirá que el desarrollador:
- Demostrar que las funcionalidades de control de incidentes se alinean con NIST Cybersecurity Framework (Identificar, Proteger, Detectar, Responder, Recuperar).
Apéndice E
Colección de evidencias: deltas para SOC 2
Cuando ya haya alcanzado el cumplimiento de SOC 2, las siguientes diferencias (brechas) no cubiertas totalmente por SOC 2 tendrán que revisarse como parte de esta certificación de Microsoft 365.
Nota:
Como parte de la evaluación de certificación de Microsoft 365, el analista de certificación determinará si alguno de los controles de SOC 2 asignados no se incluyó como parte de la evaluación de SOC 2 y también puede decidir tomar muestras de los controles que se han detectado que se han incluido para proporcionar una mayor garantía. Los requisitos que falten en la evaluación de SOC 2 deben incluirse como parte de las actividades de evaluación de la certificación de Microsoft 365.
Protección contra malware: control de aplicaciones
Si la protección contra malware está en vigor mediante el uso de antivirus y se atestigua en su informe soc 2 no es necesaria ninguna investigación adicional. Si no existe ningún antivirus, los analistas de certificación deberán identificar y evaluar las pruebas de los mecanismos de control de aplicaciones para evitar la detonación de malware dentro del entorno. Esto requerirá que:
Proporcione o muestre documentación complementaria que detalla cómo se configura el software de control de aplicaciones para cumplir los mecanismos de control de aplicaciones específicos (es decir, la lista de permitidos, la firma de código, etc.).
Muestre cómo se lleva a cabo la aprobación de la aplicación y confirme que se ha completado.
Demostrar que existe una lista completa de aplicaciones aprobadas con justificación empresarial.
Demostrar que en todos los componentes del sistema muestreados, el control de la aplicación se configura como se documenta.
Administración de revisiones: aplicación de revisiones
Como las auditorías de SOC 2 no evalúan específicamente esta categoría, esto requerirá que:
Cualquier problema bajo, medio, alto o crítico debe revisarse dentro de las ventanas de actividad de aplicación de revisiones normales.
Los componentes de software y los sistemas operativos que ya no son compatibles con el proveedor no deben usarse dentro del entorno. Las directivas auxiliares deben estar implementadas para garantizar que los componentes de software o los sistemas operativos no admitidos se quitarán del entorno y un proceso para identificar cuándo los componentes de software terminan su vida útil.
Firewall: firewalls
Como las auditorías de SOC 2 no evalúan específicamente los controles de cambio en las listas de control de acceso del firewall, esto requerirá que:
Demostrar que todo el tráfico permitido a través de los firewalls pasa por un proceso de autorización que da como resultado la documentación de todo el tráfico con una justificación empresarial.
Demostrar que las revisiones de reglas de firewall se realizan al menos cada seis meses.
Se proporcionará crédito adicional si se implementa un Web Application Firewall (WAF) o similar para ayudar a protegerse frente a la infinidad de amenazas y vulnerabilidades de aplicaciones web a las que se puede exponer la aplicación. Cuando haya un WAF o similar, esto requerirá que:
Demostrar que WAF está configurado en modo de defensa activo o supervisando más con las alertas.
Demostrar que WAF está configurado para admitir la descarga de SSL.
Se configura según el conjunto de reglas principal de OWASP ((3.0 o 3.1) para protegerse frente a la mayoría de los siguientes tipos de ataque:
✓ Problemas de protocolo y codificación.
✓ Inyección de encabezados, contrabando de solicitudes y división de respuestas.
✓ Ataques de recorrido de archivos y rutas de acceso.
✓ Ataques de inclusión remota de archivos (RFI).
✓ Ataques de ejecución remota de código.
✓ Ataques por inyección de PHP.
✓ Ataques de scripting entre sitios.
✓ Ataques por inyección de CÓDIGO SQL.
✓ Ataques de fijación de sesión.
Cambiar control
Como las auditorías de SOC 2 no evalúan específicamente algunos elementos de los procesos de solicitud de cambios, esto requerirá que el desarrollador:
Demostrar cómo los entornos de desarrollo y pruebas son independientes del entorno de producción que exige la separación de tareas.
Demostrar cómo no se usan los datos activos en los entornos de desarrollo y pruebas.
Demostrar que las pruebas de funcionalidad se realizan una vez completados los cambios.
Demostrar que las solicitudes de cambio se cierran después de realizar pruebas de funcionalidad.
Protección del desarrollo o la implementación de software
Como las auditorías de SOC 2 no acceden específicamente a algunos elementos de procesos de implementación y desarrollo de software seguros; esto le requerirá lo siguiente:
Debe tener un proceso de desarrollo de software establecido y documentado que cubra todo el ciclo de vida de desarrollo de software.
Los desarrolladores deben someterse a un entrenamiento de codificación de software seguro al menos anualmente.
Los repositorios de código deben protegerse mediante MFA.
Deben existir controles de acceso adecuados para proteger los repositorios de código frente a modificaciones de código malintencionadas.
Administración de cuentas
Dado que las auditorías de SOC2 no evalúan específicamente algunos elementos de los procesos de administración de cuentas, esto requerirá que:
Demostrar cómo se implementan los mecanismos de autorización para mitigar los ataques de reproducción (por ejemplo, MFA, Kerberos).
Muestra cómo se deshabilitan o eliminan las cuentas que no se han usado en 3 meses.
Las directivas de contraseña segura u otras mitigaciones adecuadas deben configurarse para proteger las credenciales de usuario. La siguiente directiva de contraseña mínima debe usarse como guía:
✓ Longitud mínima de contraseña de 8 caracteres.
✓ Umbral de bloqueo de cuenta de no más de 10 intentos.
✓ Historial de contraseñas de un mínimo de 5 contraseñas.
✓ Cumplimiento del uso de contraseñas seguras
Demostrar que las cuentas de usuario únicas se emiten a todos los usuarios.
Cuando la administración de DNS público está fuera del entorno dentro del ámbito, todas las cuentas de usuario que puedan realizar modificaciones de DNS deben configurarse para usar MFA.
Detección y prevención de intrusiones (OPCIONAL).
Dado que las auditorías de SOC 2 no evalúan específicamente algunos elementos de los procesos de Servicios de detección y prevención de intrusiones (IDPS), esto requerirá que:
Las firmas IDPS DEBEN mantenerse actualizadas, en el último día
IDPS DEBE configurarse para la inspección de TLS
IDPS DEBE configurarse para TODO el tráfico entrante y saliente.
Registro de eventos
Como las auditorías de SOC 2 no evalúan específicamente algunos elementos de los procesos de registro de eventos de seguridad, esto requerirá que:
- Demostrar cómo, en todos los componentes del sistema del conjunto de ejemplo, se configuran los siguientes sistemas para registrar los siguientes eventos.
✓ Acceso del usuario a los componentes del sistema y a las aplicaciones.
✓ Todas las acciones realizadas por un usuario con privilegios elevados.
✓ Intentos de acceso lógico no válidos.
Demostrar que los eventos registrados contienen; como mínimo, la siguiente información:
✓ Usuario.
✓ Tipo de evento.
✓ Fecha y hora.
✓ Indicador de éxito/error.
✓ Etiqueta para identificar el sistema afectado.
Demostrar que todos los componentes del sistema del conjunto de ejemplo están configurados para usar la sincronización de tiempo y que son los mismos que los servidores de hora principal y secundario.
Demostrar que los sistemas accesibles públicamente están registrando en una solución de registro centralizada que no está dentro de la red perimetral.
Demostrar que los sistemas accesibles públicamente están registrando en una solución de registro centralizada que no está dentro de la red perimetral.
Demostrar cómo la solución de registro centralizado está protegida frente a alteraciones no autorizadas de los datos de registro.
Demostrar cómo un mínimo de 30 días de datos de registro está disponible inmediatamente, con 90 días o más retenidos.
Administración de riesgos
Dado que las auditorías de SOC2 no evalúan específicamente algunos elementos de los procesos de evaluación de riesgos, esto requerirá que:
- Demostrar que se realiza una evaluación formal del riesgo al menos anualmente.
Respuesta a incidentes.
Como las auditorías de SOC2 no evalúan específicamente algunos elementos de las directivas y procesos de respuesta a incidentes, esto requerirá lo siguiente:
- Demostrar que el plan o procedimiento de respuesta a incidentes incluye:
✓ Procedimientos de respuesta específicos para los modelos de amenazas esperados.
✓ Proceso de comunicaciones documentado para garantizar la notificación oportuna de las partes interesadas clave (marcas de pago/adquirentes, organismos reguladores, autoridades de supervisión, directores, clientes, etc.
Apéndice F
Hospedaje de tipos de implementación
Microsoft confirma que implementará aplicaciones y almacenará código de aplicación o complemento en diferentes entornos de hospedaje. Las responsabilidades generales de algunos de los controles de seguridad dentro de la certificación de Microsoft 365 dependerán del entorno de hospedaje que se use. En el apéndice F se examinan los tipos de implementación comunes y se asignan a los controles de seguridad que se evalúan como parte del proceso de evaluación. Se han identificado los siguientes tipos de implementación de hospedaje:
| Tipos de hospedaje | Descripción |
|---|---|
| ISV hospedado | Los tipos hospedados de ISV se pueden definir como donde es responsable de la infraestructura que se usa para admitir el entorno de aplicación o complemento. Esto puede encontrarse físicamente dentro de sus propios centros de datos o centros de datos de terceros con un servicio de ubicación conjunta. En última instancia, tiene plena propiedad y control administrativo sobre la infraestructura auxiliar y el entorno operativo. |
| Infraestructura como servicio (IaaS) (https://azure.microsoft.com/overview/what-is-iaas/) | La infraestructura como servicio es un servicio que se proporciona mediante el cual el proveedor de servicios en la nube (CSP) administra y mantiene la infraestructura de soporte físico en su nombre. Normalmente, las redes, el almacenamiento, los servidores físicos y la infraestructura de virtualización son responsabilidad del CSP. El sistema operativo, middleware, tiempo de ejecución, datos y aplicaciones son las responsabilidades de usted. Las funcionalidades de firewall también serían administradas y mantenidas por el tercero, sin embargo, el mantenimiento de la base de reglas de firewall normalmente seguiría siendo la responsabilidad de los consumidores. |
| Plataforma como servicio/sin servidor (PaaS) (https://azure.microsoft.com/overview/what-is-paas/) | Con Plataforma como servicio, se aprovisiona con una plataforma administrada que presenta un servicio que se puede consumir. No es necesario realizar funciones sysadmin, ya que el CSP administra el sistema operativo y la infraestructura auxiliar. Normalmente, esto se usaría cuando las organizaciones no quieren preocuparse por presentar un servicio web y, en su lugar, pueden concentrarse en crear el código fuente de la aplicación web y publicar la aplicación web en los servicios web administrados en la nube. Otro ejemplo puede ser un servicio de base de datos en el que se proporciona conectividad a una base de datos, pero la infraestructura auxiliar y la aplicación de base de datos se abstrae del consumidor. Nota: Serverless y PaaS son similares, por lo que para el propósito del tipo de implementación de hospedaje de certificación de Microsoft 365 sin servidor y PasS se consideran iguales |
| Hospedado híbrido | Con el tipo hospedado híbrido, puede usar varios tipos hospedados para admitir varias partes del entorno auxiliar. Este puede ser más el caso en el que las aplicaciones o complementos se usan en varias pilas de Microsoft 365. Aunque la certificación de Microsoft 365 admitirá dónde se desarrollan aplicaciones o complementos en varios servicios de Microsoft 365, una evaluación de todo el entorno compatible (entre aplicaciones o complementos) tendría que evaluarse de acuerdo con cada una de las "asignaciones de tipos hospedados" aplicables. En ocasiones, puede usar diferentes tipos hospedados para un único complemento, donde esto se está llevando a cabo, la aplicabilidad de los criterios tendrá que seguir los criterios "Asignaciones de tipos hospedados" en los distintos tipos hospedados. |
| Hospedaje compartido | El hospedaje compartido es donde hospeda el entorno dentro de una plataforma que comparten varios consumidores individuales. La especificación de certificación de Microsoft 365 no se escribió para tener en cuenta esto debido a la adopción de la nube, el hospedaje compartido no es común. Si cree que se está usando, póngase en contacto con Microsoft, ya que será necesario crear requisitos adicionales para tener en cuenta los riesgos adicionales en este tipo de hospedaje. |
Apéndice G
Más información
Introducción al programa de cumplimiento de aplicaciones de Microsoft 365 ¿Qué es la atestación del publicador de aplicaciones de Microsoft 365?¿Qué es la certificación de Microsoft 365?
Glosario
AIA
*Authority Information Access es un descriptor de ubicación de servicio que se usa para buscar el certificado de la entidad de certificación emisora.
CRL
*La lista de revocación de certificados proporciona un medio para que un punto de conexión de capa de sockets seguros (SSL) compruebe que un certificado recibido de un host remoto es válido y confiable.
Puntuación de CVSS
*Common Vulnerability Scoring System es un estándar publicado que mide la vulnerabilidad y calcula una puntuación numérica en función de su gravedad.
Directrices de administración de revisiones de CVSS
- Crítico (9.0 - 10.0)
- Alto (7.0 - 8.9)
- Medio (4.0 - 6.9)
- Bajo (0,0 - 3,9)
DMZ
*La zona desmilitarizada es una red intermedia física o lógica que interactúa directamente con redes externas o que no son de propiedad mientras mantiene la red interna y privada del host separada y aislada.
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.
EUII
Información de identificación del usuario final.
RGPD
*El Reglamento General de Protección de Datos es un reglamento de privacidad y protección de datos de la Unión Europea (UE) para todos los datos de los ciudadanos de la UE, independientemente de dónde se encuentre su sitio de aplicación.
HSTS
*Http Strict Transport Security utiliza un encabezado de respuesta HTTP que indica al explorador web que solo acceda al contenido a través de HTTPS. Esto está diseñado para protegerse frente a ataques de degradación y secuestro de cookies.
IEC
*Comisión Electrotécnica Internacional.
SGSI
*Sistema de administración de seguridad de la información.
ISV
Los proveedores de seguridad independientes son personas y organizaciones que desarrollan, comercializan y venden software que se ejecuta en plataformas de hardware y software de terceros.
ISO 27001
Marco de especificación del sistema de administración de la seguridad de la información para todos los controles técnicos de las directivas y procedimientos de administración de riesgos de una organización.
LFI
La inclusión de archivos local permite a un atacante incluir archivos en un servidor a través del explorador web.
NIST
El Instituto Nacional de Estándares (NIST), una agencia no reguladora del Departamento de Comercio de LOS EE. UU., proporciona orientación a las organizaciones del sector privado en LOS EE. UU. para evaluar y aprobar su capacidad de prevenir, detectar y responder a ciberataques.
Cambios no significativos
- Correcciones de errores menores.
- Mejoras de rendimiento menores.
- Sistemas operativos, bibliotecas o revisiones de aplicaciones cliente y servidor.
OCSP
El protocolo de estado de certificado en línea se usa para comprobar el estado de revocación de los certificados digitales X.509.
OII
Información de identificación de la organización.
OWASP
Abra proyecto de seguridad de aplicaciones web.
PCI DSS
Estándar de seguridad de datos del sector de tarjetas de pago, una organización que mantiene estándares para la seguridad de los datos de los titulares de tarjetas en todo el mundo.
Pruebas de lápiz
Las pruebas de penetración son un método para probar una aplicación web mediante la simulación de ataques malintencionados para encontrar vulnerabilidades de seguridad que un atacante podría aprovechar.
SAML
El lenguaje de marcado de aserción de seguridad es un estándar abierto para intercambiar datos de autenticación y autorización entre el usuario, el proveedor de identidades y el proveedor de servicios.
Datos confidenciales
- Datos de control de acceso.
- Contenido del cliente.
- Información de identidad del usuario final.
- Datos de soporte técnico.
- Datos personales públicos.
- Información seudónima del usuario final.
Cambios significativos
- Reubicación del entorno de hospedaje.
- Principales actualizaciones de la infraestructura auxiliar; por ejemplo, la implementación de un nuevo firewall, las actualizaciones principales de los servicios frontales, etc.
- Adición de funcionalidades y /o extensiones a la aplicación.
- Novedades a la aplicación que captura datos confidenciales adicionales.
- Cambios en los flujos de datos o modelos de autorización de la aplicación
- Adición de puntos de conexión de API o funciones de punto de conexión de API.
SOC 2
Service Organization Control 2, un procedimiento de auditoría técnica compuesto por cinco principios de servicio de confianza para garantizar que los proveedores de servicios administren de forma segura los datos y la privacidad de los clientes de una organización.
SSL
Capa de sockets seguros.
TLS
Seguridad de la capa de transporte.