Dominio de seguridad: control de datos de seguridad y privacidad

Este dominio de seguridad está diseñado para garantizar que los datos consumidos de Microsoft 365 estén protegidos adecuadamente tanto en tránsito como en reposo. Este dominio también garantiza que los problemas de privacidad de los consumidores (interesados) están siendo cumplidos por el ISV, de conformidad con el RGPD (Reglamento general de protección de datos) y hipaa (Ley de portabilidad y responsabilidad de seguros de salud de 1996).

Datos en tránsito

Los requisitos de conectividad de aplicaciones o complementos desarrollados por Microsoft 365 requieren comunicación a través de redes públicas, específicamente Internet. Por lo tanto, los datos en tránsito deben protegerse adecuadamente. En esta sección se trata la protección de las comunicaciones de datos a través de Internet.

Control Nº 1

Proporcione pruebas de lo siguiente:

• Valide que la configuración de TLS es TLS1.2 o posterior.

• Se mantiene y mantiene un inventario de claves y certificados de confianza.

Intención: TLS

La intención de este subpunto es asegurarse de que los datos de Microsoft 365 que consume su organización se transmiten de forma segura. La configuración del perfil TLS se usa para definir requisitos específicos de TLS que ayudan a garantizar que el tráfico es seguro frente a ataques de tipo "man in the middle".

Directrices: TLS

La manera más fácil de demostrar esto es ejecutar la herramienta de prueba de servidor SSL de Qualys en TODOS los agentes de escucha web, incluidos los que se ejecutan en puertos no estándar.

Recuerde marcar la opción "No mostrar los resultados en los paneles", lo que impide que la dirección URL se agregue al sitio web.

Los requisitos de configuración del perfil TLS se pueden demostrar proporcionando pruebas de comprobaciones individuales. Para proporcionar pruebas de configuraciones específicas, como deshabilitar la compresión TLS, se pueden usar valores de configuración, scripts y herramientas de software.

Evidencia de ejemplo: TLS

En la captura de pantalla siguiente se muestran los resultados del examen SSL de Qualys para la webappfrontdoor- byendbagh6a0fcav.z01.azurefd.net.

En la sección Protocolos se muestra que TLS1.2 es el único protocolo compatible o habilitado.

Nota: Los analistas de certificación revisarán la salida completa del examen para confirmar que se cumplen todos los requisitos de configuración del perfil TLS. La expectativa será que se proporcionen exámenes para todos los puntos finales que se exponen públicamente (direcciones IP y direcciones URL) al entorno back-end que está en el ámbito. En función de las pruebas que se hayan proporcionado, los analistas pueden ejecutar su propio examen de Qualys.

Evidencia de ejemplo: TLS

En la captura de pantalla siguiente se muestran los valores de configuración de TLS en Azure App Service seguidos de la enumeración TLS a través de PowerShell.

Intención: claves y certificados

La intención de este subpunto es asegurarse de que se mantiene un inventario completo de claves y certificados de confianza, lo que implica la identificación de varios sistemas, servicios y aplicaciones que dependen de estos elementos criptográficos.

Directrices: claves y certificados

La evidencia debe demostrar que existe un inventario de claves y certificados de confianza y se mantiene. Además, se pueden proporcionar pruebas aplicables de las herramientas usadas para almacenar las claves y certificados reales, como Azure Key Vault, HashiCorp Vault Secrets, Confluence Cloud, etc.

Evidencia de ejemplo: claves y certificados

En la captura de pantalla siguiente se muestra que una clave y un inventario de certificados se mantienen en Confluence Cloud.

En la captura de pantalla siguiente se muestra la lista aprobada de claves y certificados de confianza. Incluye detalles como el certificado, las claves, los chiphers y los sistemas en los que están instalados.

La captura de pantalla siguiente es de HashiCorp Vault. Los certificados que se describen y registran en la lista de inventario se almacenan en este almacén en línea. HashiCorp Vault es una herramienta de código abierto para la administración de secretos, el cifrado como servicio y la administración de acceso con privilegios.

La captura de pantalla siguiente es un extracto del certificado real y las claves almacenadas dentro del almacén en línea.

Nota: La expectativa será que la ubicación de almacenamiento de las claves tenga los controles de acceso adecuados. Si la clave privada está en peligro, alguien podría suplantar el servidor con un certificado legítimo.

Evidencia de ejemplo: claves y certificados

También se puede mantener un inventario de claves y certificados de confianza con Microsoft 365 Defender, que proporciona una característica inventario, como se muestra en la siguiente captura de pantalla.

En la captura de pantalla siguiente se muestran los detalles del certificado.

Tenga en cuenta: Estos ejemplos no son capturas de pantalla completa, se le pedirá que envíe capturas de pantalla completa con cualquier dirección URL, el usuario que ha iniciado sesión y la marca de fecha y hora para la revisión de pruebas. Si es un usuario de Linux, esto se puede hacer a través del símbolo del sistema.

Control Nº 2

Proporcione pruebas de lo siguiente:

• Muestra que la compresión TLS está deshabilitada para todos los servicios orientados al público que controlan las solicitudes web para evitar CRIME (pérdida de información de relación de compresión que facilita).

• Valida que TLS HSTS está habilitado y configurado en 180 días en todos los sitios.

Intención: TLS

• El ataque CRIME (pérdida de información de relación de compresión que se facilita (CVE-2012-4929)) es una vulnerabilidad en la compresión de los protocolos De capa de sockets seguros (SSL)/Seguridad de la capa de transporte (TLS). Por este motivo, las recomendaciones del sector son deshabilitar la compresión SSL.

• Http Strict Transport Security (HSTS) es un mecanismo de seguridad diseñado para proteger los sitios web frente a ataques de tipo "man in the middle" al forzar conexiones TLS mediante un campo de encabezado de respuesta HTTPS denominado "Strict-Transport-Security".

Directrices: TLS

Esto se puede demostrar a través de la herramienta Qualys SSL Labs. Evidencia de ejemplo: TLS

En la captura de pantalla siguiente se muestra que la compresión SSL/TLS está deshabilitada.

En la captura de pantalla siguiente se muestra que HSTS está habilitado.

Nota: El analista de certificación revisará la salida completa para confirmar que se cumplen todos los requisitos de configuración del perfil TLS (proporcione capturas de pantalla de la salida del examen completo). En función de las pruebas que se hayan proporcionado, los analistas pueden ejecutar su propio examen de Qualys.

Otras herramientas que se pueden usar para comprobar que HSTS está habilitado son "HTTP Header Spy" y

securityheaders.com como se muestra en los ejemplos siguientes. Pruebas adicionales

Se pueden proporcionar capturas de pantalla, como la configuración de los encabezados de seguridad, específicamente HSTS para demostrar aún más la posición de seguridad de la superficie pública.

En las capturas de pantalla siguientes se muestra la configuración de Azure Front Door y el conjunto de reglas implementado para volver a escribir los encabezados.

En la captura de pantalla siguiente se muestra el examen de encabezados de seguridad realizado y que se implementan todos los encabezados de seguridad, no solo HSTS.

Nota: Si se usan el analizador SSL de Qualys o los encabezados de seguridad, la expectativa será que se proporcione el informe completo para una revisión.

Datos en reposo

Cuando los ISV almacenan los datos consumidos desde la plataforma de Microsoft 365, los datos deben protegerse adecuadamente. En esta sección se tratan los requisitos de protección de los datos almacenados en bases de datos y almacenes de archivos.

Control Nº 3

Proporcione pruebas demostrables de que los datos en reposo se cifran de acuerdo con los requisitos del perfil de cifrado, mediante algoritmos de cifrado como AES, Blowfish, TDES y tamaños de clave de cifrado de 128 bits y 256 bits.

Intención:

Se sabe que algunos algoritmos de cifrado antiguos contienen algunas debilidades criptográficas, lo que aumenta las posibilidades de que un actor de amenazas pueda descifrar los datos sin conocimiento de la clave. Por este motivo, la intención de este control es garantizar que solo se usen algoritmos de cifrado aceptados por el sector para proteger los datos almacenados de M365.

Directrices:

La evidencia se puede proporcionar mediante capturas de pantalla, que muestran el cifrado que se emplea para proteger los datos M365 dentro de bases de datos y otras ubicaciones de almacenamiento. La evidencia debe demostrar que la configuración de cifrado está en consonancia con los requisitos de configuración del perfil de cifrado de la certificación de Microsoft 365.

Evidencia de ejemplo:

En la captura de pantalla siguiente se muestra que TDE (cifrado de datos transparente) está habilitado en la base de datos de Contoso. En la segunda captura de pantalla se muestra la página de documentación de Microsoft Cifrado de datos transparente para SQL Database, INSTANCIA administrada de SQL y Azure Synapse Analytics que muestra que el cifrado AES 256 se usa para Azure TDE.

Nota: En los ejemplos anteriores no se usaron capturas de pantalla completas, pero todas las capturas de pantalla de pruebas enviadas por ISV deben ser capturas de pantalla completas que muestren la dirección URL, la hora y la fecha de inicio de sesión del usuario y del sistema.

Evidencia de ejemplo:

En la captura de pantalla siguiente se muestra Azure Storage configurado con cifrado para blobs y archivos. En la captura de pantalla siguiente se muestra la página documentación de Microsoft Cifrado de Azure Storage para datos en reposo que muestra que Azure Storage usa AES-256 para el cifrado.

Retención, copia de seguridad y eliminación de datos

Cuando los ISV consumen y almacenan datos de Microsoft 365, existe el riesgo de que un actor de amenazas ponga en peligro el entorno de ISV. Para minimizar este riesgo, las organizaciones solo deben conservar los datos que necesitan para entregar servicios y no los datos que "puedan" usar en el futuro. Además, los datos solo se deben conservar durante el tiempo necesario para proporcionar los servicios para los que se capturaron los datos. La retención de datos debe definirse y comunicarse con los usuarios. Una vez que los datos superan el período de retención definido, se deben eliminar de forma segura para que los datos no se puedan reconstruir ni recuperar.

Control Nº 4

Proporcione pruebas de que se ha establecido y documentado formalmente un período de retención de datos aprobado.

Intención:

Una política de retención documentada y seguida es importante no solo para cumplir algunas obligaciones legales, por ejemplo, la legislación de privacidad de datos como, entre otras, el Reglamento general de protección de datos (RGPD de la UE) y la Ley de protección de datos (DPA del Reino Unido 2018), sino también para limitar el riesgo de las organizaciones. Al comprender los requisitos de datos de las organizaciones y cuánto tiempo se necesitan para que la empresa realice sus funciones, las organizaciones pueden asegurarse de que los datos se eliminen correctamente una vez que expire su utilidad. Al reducir los volúmenes de datos almacenados, las organizaciones reducen la cantidad de datos que se expondrían en caso de que se produzca un riesgo de datos. Esto limitará el impacto general.

A menudo, las organizaciones almacenarán datos porque es agradable tenerlos por si acaso. Sin embargo, si la organización no necesita los datos para realizar su servicio o función empresarial, los datos no deben almacenarse, ya que esto aumenta innecesariamente el riesgo de la organización.

El objetivo de este control es confirmar que la organización ha establecido y documentado formalmente un período de retención de datos aprobado para todos los tipos de datos pertinentes. Esto implica no solo especificar la duración durante la que se almacenarán los distintos tipos de datos, sino también definir los procedimientos para la eliminación de datos o el archivo después de la expiración.

Directrices:

Proporcione la directiva de retención de datos completa que detalla claramente cuánto tiempo deben conservarse los datos (debe cubrir todos los tipos de datos) para que la empresa pueda realizar sus funciones empresariales.

Evidencia de ejemplo:

En la captura de pantalla siguiente se muestra la directiva de retención de datos de Contoso.

Nota: Estas capturas de pantalla muestran una instantánea de un documento de directiva o proceso. La expectativa es que los ISV compartan la documentación real de procedimientos o directivas auxiliares y no simplemente proporcionen una captura de pantalla.

Control Nº 5

Demostrar que los datos solo se conservan durante el período de retención definido, como se describe en el control 4.

Intención:

La intención de este control es simplemente validar que se cumplen los períodos de retención de datos definidos. Como ya se ha comentado, las organizaciones pueden tener la obligación legal de cumplir esto, pero también manteniendo los datos necesarios y durante el tiempo necesario ayuda a reducir el riesgo para la organización en caso de que se produzca una vulneración de datos. Esto garantiza que los datos no se conserven durante una duración excesivamente larga ni se eliminen prematuramente, lo que podría suponer riesgos de naturaleza variable (legales, operativas o relacionadas con la seguridad).

Directrices:

Proporcione pruebas de captura de pantalla (o a través de un recurso compartido de pantalla) que muestren que los datos almacenados (en todas las distintas ubicaciones de datos, es decir, bases de datos, recursos compartidos de archivos, archivos, etc.) no superan la directiva de retención de datos definida. Algunos ejemplos pueden ser capturas de pantalla de:

• registros de base de datos con un campo de fecha, buscados en el orden de registro más antiguo y/o

• Ubicaciones de almacenamiento de archivos que muestran marcas de tiempo que se encuentran dentro del período de retención Nota: Los datos personales o confidenciales de los clientes deben redactarse en la captura de pantalla.

Evidencia de ejemplo:

La siguiente evidencia muestra una consulta SQL que muestra el contenido de la tabla de base de datos ordenada en orden ascendente en el campo "DATE_TRANSACTION" para mostrar los registros más antiguos de la base de datos. Esto muestra que los datos tiene menos de dos meses de antigüedad, lo que no supera el período de retención definido.

Nota: Se trata de una base de datos de prueba, por lo que no hay muchos datos históricos dentro de ella.

Nota: En los ejemplos anteriores no se usaron capturas de pantalla completas, pero todas las capturas de pantalla de pruebas enviadas por ISV deben ser capturas de pantalla completas que muestren la dirección URL, la hora y la fecha de inicio de sesión del usuario y del sistema.

Control Nº 6

Demostrar que los procesos están en vigor para eliminar datos de forma segura después de su período de retención.

Intención:

La intención de este control es asegurarse de que el mecanismo utilizado para eliminar datos que superan el período de retención lo está haciendo de forma segura. Los datos eliminados a veces se pueden recuperar; por lo tanto, el proceso de eliminación debe ser lo suficientemente sólido como para garantizar que los datos no se puedan recuperar una vez eliminados.

Directrices:

Si el proceso de eliminación se realiza mediante programación, proporcione una captura de pantalla del script que se usa para realizarlo. Si se ejecuta según una programación, proporcione una captura de pantalla que muestre la programación. Por ejemplo, un script para eliminar archivos dentro de un recurso compartido de archivos se puede configurar como un trabajo CRON, captura de pantalla del trabajo CRON que muestra la programación y el script que se ejecuta; y proporcione el script que muestra el comando usado.

Evidencia de ejemplo:

Se trata de un script sencillo que se podría usar para eliminar todos los registros de datos retenidos en función de la fecha -WHERE DateAdd es de -30 días, lo que purgará todos los registros retenidos anteriores a 30 días después de la fecha de retención de datos seleccionada. Tenga en cuenta que necesitaremos el script; evidencia del trabajo que se está ejecutando y los resultados.

Nota: En los ejemplos anteriores no se usaron capturas de pantalla completas, pero todas las capturas de pantalla de pruebas enviadas por ISV deben ser capturas de pantalla completas que muestren la dirección URL, la hora y la fecha de inicio de sesión del usuario y del sistema.

Evidencia de ejemplo:

La captura de pantalla siguiente se ha tomado de la directiva de retención de datos de Contoso (del control 4): muestra los procedimientos usados para la destrucción de datos.

Nota: Esta captura de pantalla muestra una instantánea de un documento de directiva o proceso. La expectativa es que los ISV compartan la documentación real de procedimientos o directivas auxiliares y no simplemente proporcionen una captura de pantalla.

Evidencia de ejemplo:

En este ejemplo se ha creado un Runbook y una programación correspondiente en Azure para eliminar de forma segura los registros que tienen una fecha de finalización creada a partir de los 30 días posteriores a la expiración de la directiva de retención de registros de datos. Este trabajo se establece para ejecutarse cada mes el último día del mes.

En la captura de pantalla siguiente se muestra que el Runbook se ha editado para buscar registros y que tiene comandos de eliminación que no están en la vista, como el script.

Nota: La dirección URL completa y el nombre de usuario deben estar en vista para estas capturas de pantalla y los ISV serán necesarios para mostrar una captura de pantalla de antes del recuento de registros de eliminación y una captura de pantalla del recuento de registros después de la eliminación.

Estas capturas de pantalla son simplemente ejemplos de las distintas formas en que se puede abordar esto.

Control Nº 7

Proporcione pruebas que demuestren lo siguiente:

• Un sistema de copia de seguridad automatizado está implementado y configurado para realizar copias de seguridad a horas programadas.

• La información de copia de seguridad 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.

• 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.

Intención:

El objetivo de este control es confirmar que la organización tiene un sistema de copia de seguridad automatizado, que está configurado para ejecutar copias de seguridad en tiempos predeterminados.

Directrices:

Proporcione capturas de pantalla de los valores de configuración de la solución de copia de seguridad que muestran que las copias de seguridad se realizan en períodos o intervalos de tiempo programados. Si la solución realiza automáticamente la programación de copia de seguridad, puede ser compatible con la documentación del proveedor.

Evidencia de ejemplo:

La captura de pantalla siguiente se aplica a Azure Database for MySQL, que es una instancia administrada. Indica que se ha completado una primera copia de seguridad automatizada.

La siguiente captura de pantalla se realiza una vez transcurrido un período que muestra que se han realizado más copias de seguridad completas. Las copias de seguridad en servidores flexibles se basan en instantáneas, donde la primera copia de seguridad de instantáneas se programa inmediatamente después de crear un servidor y se realizan más copias de seguridad de instantáneas una vez al día.

En la captura de pantalla siguiente se muestra una instantánea de documentación en línea que describe la frecuencia de copia de seguridad y la funcionalidad de copia de seguridad automatizada.

Intención:

El objetivo de este control es confirmar que la información de copia de seguridad no solo se genera según la programación, sino que también es confiable y mantiene su integridad a lo largo del tiempo. Para cumplir este objetivo, se realizarán pruebas periódicas en los datos de copia de seguridad.

Directrices:

Las pruebas para cumplir este control dependerán del proceso y el procedimiento de la organización para probar los datos de copia de seguridad. Se pueden proporcionar pruebas que muestren que las copias de seguridad se prueban correctamente junto con los registros de finalización de pruebas históricas.

Evidencia de ejemplo:

En la captura de pantalla siguiente se muestra que existe un procedimiento de programación y restauración de copia de seguridad y se mantiene y que se define una configuración de copia de seguridad para todos los sistemas aplicables, incluida la frecuencia de las copias de seguridad que se realizan en la plataforma de Confluence.

En la captura de pantalla siguiente se muestra una página de registros históricos de pruebas de copia de seguridad para cada uno de los sistemas aplicables. Observe que en el lado derecho de la tabla se hace referencia a los vales JIRA para cada una de las pruebas.

Las cuatro capturas de pantalla siguientes muestran el proceso completo de restauración de Azure Database for MySQL a partir de una instantánea. Con la opción "Restauración rápida", podemos iniciar el proceso de restauración de la base de datos SQL.

En la captura de pantalla siguiente se muestra la página de configuración donde se puede personalizar la restauración.

Una vez seleccionada la ubicación de destino, las redes y la instantánea desde la que se restaurará la base de datos, podemos iniciar la implementación. Observe que nuestra instancia de base de datos se denomina ahora "test".

Después de un total de cinco minutos, la base de datos SQL se restauró correctamente y totalmente a partir de la instantánea de copia de seguridad, como se muestra a continuación.

Una vez completadas las pruebas, de acuerdo con el proceso, se creó un vale JIRA para registrar las pruebas de copia de seguridad y los detalles de la restauración realizada. Esto garantiza que los datos históricos estén disponibles con fines de cumplimiento, así como que existan registros completos para su revisión en la eventualidad de un incidente o desastre para permitir que la organización realice un análisis de la causa principal.

Intención:

A partir del control anterior, se deben implementar controles de acceso para limitar el acceso solo a usuarios individuales responsables de los datos de copia de seguridad. Al limitar el acceso, está limitando el riesgo de que se realicen cambios no autorizados y, por tanto, introducir cambios inseguros. Se debe adoptar un enfoque con privilegios mínimos para proteger las copias de seguridad.

Para proteger correctamente los datos, las organizaciones deben tener en cuenta qué datos consume su entorno o sistemas y dónde se almacenan los datos. Una vez que esto se comprenda y documente por completo.

A continuación, las organizaciones no solo pueden implementar una protección de datos adecuada, sino que también pueden consolidar dónde se encuentran los datos para implementar la protección de forma más eficaz. Además, cuando los datos se consolidan en el menor número posible, es mucho más fácil implementar un control de acceso basado en rol (RBAC) adecuado para limitar el acceso a los pocos empleados que sea necesario.

Directrices:

Se debe proporcionar evidencia del sistema o tecnología que se usa para demostrar los permisos de acceso a las copias de seguridad y las soluciones de copia de seguridad con documentación complementaria de la lista de acceso aprobada.

Evidencia de ejemplo:

Podemos ver en las capturas de pantalla siguientes que los controles de acceso se implementan en la instancia de base de datos para restringir el acceso solo a los usuarios autorizados en función del rol de trabajo.

Evidencia de ejemplo:

Azure administra las copias de seguridad automatizadas de Azure SQL Database y Azure SQL Managed Instances y su integridad es responsabilidad de la plataforma Azure; ningún usuario tiene acceso a ellos, y se cifran en reposo sin posibilidad de ataques de ransomware. También se replican en otras regiones para su protección.

Administración del acceso a datos

El acceso a datos necesita limitarse a tan pocas personas como sea necesario para reducir las posibilidades de que los datos se vean comprometidos de forma malintencionada o accidental. El acceso a los datos y las claves de cifrado debe limitarse a los usuarios con una necesidad empresarial legítima de acceso para cumplir su rol de trabajo. Se debe implementar un proceso bien documentado y bien establecido para solicitar acceso. El acceso a los datos y las claves de cifrado debe seguir el principio de privilegios mínimos.

Control Nº 8

Proporcione pruebas para demostrar que una lista de personas con acceso a datos o claves de cifrado:

• se mantiene incluyendo la justificación empresarial para cada individuo.

• se aprobaron formalmente en función de los privilegios de acceso necesarios para su función de trabajo.

• se configuran con los privilegios descritos en la aprobación.

Intención:

Las organizaciones deben limitar el acceso a los datos y las claves de cifrado al menor número posible de empleados. La intención de este control es garantizar que el acceso de los empleados a los datos o las claves de cifrado esté restringido a los empleados con una necesidad empresarial clara de dicho acceso.

Directrices:

Documentación o capturas de pantalla de sistemas internos que documenta a todos los empleados con acceso a datos o claves de cifrado junto con la justificación empresarial de por qué estas personas tienen acceso deben proporcionarse. El analista de certificación usará esta lista para muestrear a los usuarios para los controles siguientes.

Evidencia de ejemplo:

En el documento siguiente se muestra la lista documentada de usuarios con acceso a los datos y la justificación empresarial.

Nota: En esta captura de pantalla se muestra un documento de directiva o proceso, la expectativa es que los ISV compartan la documentación real sobre directivas o procedimientos auxiliares.

Intención:

El proceso para conceder acceso a datos o claves de cifrado debe incluir aprobación, lo que garantiza que se requiere el acceso de una persona para su función de trabajo. Esto garantiza que los empleados sin una verdadera razón de acceso no obtengan acceso innecesario.

Directrices:

Normalmente, la evidencia proporcionada para el control anterior puede ayudar a admitir este control. Si no hay una aprobación formal en la documentación proporcionada, las pruebas pueden constar de que se ha generado y aprobado una solicitud de cambio para el acceso dentro de una herramienta como Azure DevOps o Jira.

Evidencia de ejemplo:

Este conjunto de imágenes muestra los vales de Jira creados y aprobados para que el control (i) conceda o deniegue el acceso a datos confidenciales o claves de cifrado. Esta imagen muestra que se ha creado una solicitud en Jira para obtener la aprobación diaria de Sam para las claves de cifrado en el entorno de back-end de los sistemas. Esto se hace como el siguiente paso en el que se ha obtenido la autorización por escrito.

Esto muestra que jon smith ha aprobado la solicitud de acceso diario de Sam a una persona de la administración. (Tenga en cuenta que la aprobación debe proceder de alguien con autoridad suficiente para permitir la solicitud de cambio, no puede ser otro desarrollador).

El anterior muestra un flujo de trabajo en Jira para este proceso. Tenga en cuenta que no se puede agregar nada como Hecho a menos que haya pasado por el proceso de aprobación que está automatizado y, por tanto, no se puede omitir.

El panel Proyecto ahora muestra que se ha aprobado el acceso de Sam Daily a las claves de cifrado. En el trabajo pendiente siguiente se muestra la aprobación de la solicitud de Sam Daily y la persona asignada para realizar el trabajo.

Para cumplir los requisitos de este control, debe mostrar todas estas capturas de pantalla o pruebas similares o equivalentes aplicables con una explicación para demostrar que ha cumplido el requisito de control.

Nota: En los ejemplos anteriores no se usaron capturas de pantalla completas, pero todas las capturas de pantalla de pruebas enviadas por ISV deben ser capturas de pantalla completas que muestren la dirección URL, la hora y la fecha de inicio de sesión del usuario y del sistema.

Evidencia de ejemplo:

En el siguiente ejemplo, se han solicitado permisos de acceso de administrador y control total para un usuario a la base de datos de producción. La solicitud se ha enviado para su aprobación, como se puede ver a la derecha de la imagen y se ha aprobado como se muestra a la izquierda.

La siguiente imagen indica que el acceso se ha aprobado y firmado como se ha hecho.

Nota: En los ejemplos anteriores no se usaron capturas de pantalla completas, pero todas las capturas de pantalla de pruebas enviadas por ISV deben ser capturas de pantalla completas que muestren la dirección URL, la hora y la fecha de inicio de sesión del usuario y del sistema.

Intent

La intención de este subpunto es confirmar que el acceso a los datos o a la clave de cifrado está configurado según lo documentado.

Directrices:

La evidencia se puede proporcionar mediante una captura de pantalla que muestra los datos o los privilegios de acceso de clave de cifrado concedidos a las personas muestreadas. La evidencia debe cubrir todas las ubicaciones de datos.

Evidencia de ejemplo:

En esta captura de pantalla se muestran los permisos concedidos al usuario "John Smith" que serían cruzados

se hace referencia a la solicitud de aprobación de este mismo usuario según las pruebas del control anterior.

Tenga en cuenta que el ejemplo siguiente no es una captura de pantalla completa, se le pedirá que envíe capturas de pantalla completa con cualquier dirección URL, el usuario que ha iniciado sesión y la marca de fecha y hora para la revisión de pruebas. Si es un usuario de Linux, esto se puede hacer a través del símbolo del sistema.

Control Nº 9

Proporcione pruebas de que:

• Se mantiene una lista de todos los terceros con los que se comparten los datos.

• Los acuerdos de uso compartido de datos están vigentes con todos los terceros que consumen datos.

Intención:

Cuando se usan terceros para el almacenamiento o el procesamiento de datos de Microsoft 365, estas entidades pueden suponer un riesgo significativo. Las organizaciones deben desarrollar un buen proceso de administración y diligencia debida de terceros para garantizar que estos terceros almacenan o procesan datos de forma segura y para asegurarse de que respetarán las obligaciones legales que puedan tener, por ejemplo, como procesador de datos en virtud del RGPD.

Las organizaciones deben mantener una lista de todos los terceros con los que comparten datos con algunos o todos los siguientes:

• ¿Qué servicios se proporcionan?

• qué datos se comparten

• por qué se comparten los datos

• información de contacto clave (es decir, contacto principal, contacto de notificación de infracción, DPO, etc.)

• renovación o expiración del contrato

• obligaciones legales o de cumplimiento (es decir, RGPD, HIPAA, PCI DSS, FedRAMP, etc.)

Directrices:

Proporcione documentación en la que se detallan todos los terceros con los que se comparten los datos de Microsoft 365.

Nota: Si terceros no están en uso, será necesario confirmarlo por escrito (correo electrónico) por un miembro del equipo directivo sénior.

Evidencia de ejemplo:

Nota: - En los ejemplos anteriores no se usaron capturas de pantalla completas, pero todas las capturas de pantalla de pruebas enviadas por ISV deben ser capturas de pantalla completas que muestren la dirección URL, la hora y la fecha de inicio de sesión del usuario y del sistema.

Evidencia de ejemplo:

En la captura de pantalla siguiente se muestra un ejemplo de correo electrónico de un miembro del equipo directivo sénior que confirma que no se usan terceros para procesar datos de Microsoft 365.

Nota: - En estos ejemplos no se usaron capturas de pantalla completas, pero todas las capturas de pantalla de pruebas enviadas por ISV deben ser capturas de pantalla completas que muestren la dirección URL, la hora y la fecha de inicio de sesión del usuario y del sistema.

Intención:

Cuando los datos de M365 se comparten con terceros, es importante que los datos se administren de forma adecuada y segura. Los acuerdos de uso compartido de datos deben establecerse para garantizar que terceros solo procesan datos según sea necesario y que comprenden sus obligaciones de seguridad. La seguridad de las organizaciones es tan fuerte como el vínculo más débil. La intención de este control es asegurarse de que los terceros no se conviertan en un vínculo débil de las organizaciones.

Directrices:

Proporcione los acuerdos de uso compartido de datos vigentes con terceros.

Evidencia de ejemplo:

En la captura de pantalla siguiente se muestra un ejemplo simplista de un acuerdo de uso compartido de datos.

Nota: El contrato completo debe compartirse y no una captura de pantalla.

Privacidad

El cumplimiento de la privacidad y la administración de la información son esenciales para proteger los derechos de las personas y garantizar el control responsable de los datos. Para que una organización establezca un sistema de información de privacidad eficaz, deben ser conscientes de los datos personales que contienen y del propósito de procesar y almacenar dichos datos. Una organización debe asignar el flujo de información y cómo se procesa, reconociendo que pueden producirse varios tipos diferentes de procesamiento.

Control Nº 10

¿Tiene su organización 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 saber cómo se mantienen sus 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.

Intención:

La intención de este punto es asegurarse de que existe una "cultura de privacidad" y es apoyada por el liderazgo de la organización a través de un programa de gobernanza de privacidad eficaz. La administración de la organización debe demostrar a través de su documentación y procesos establecidos que existe un sistema de administración de privacidad eficaz, dichos procesos están alineados con los objetivos estratégicos de la organización y se establecen dentro del contexto y las circunstancias de la organización, así como asegurarse de que el sistema de administración de privacidad está insertado dentro de los procesos empresariales.

Directrices:

Esto se demostraría proporcionando la documentación establecida de la organización que describe la directiva y el procedimiento de Administración de la información de privacidad (PIM). Los analistas de certificación revisarán esto para asegurarse de que se aborda toda la información proporcionada dentro del control.

Evidencia de ejemplo:

En las capturas de pantalla siguientes se muestran instantáneas de una directiva pim.

Tenga en cuenta: La expectativa es que los ISV compartan la documentación real de procedimientos o directivas auxiliares y no simplemente proporcionen una captura de pantalla.

Intent

La responsabilidad es uno de los principios clave de la ley de protección de datos, ya que permite a una organización minimizar los riesgos asociados con su tratamiento de datos personales mediante la implementación de directivas, procedimientos y procesos adecuados y eficaces. Estas medidas deben ser proporcionales a los riesgos, que pueden variar en función de la cantidad de datos que se manipulan o transfieren, su sensibilidad y la tecnología en uso. Para lograr esto, cada empleado debe saber quién es responsable de los diversos elementos del sistema de administración de privacidad para garantizar una implementación correcta. Al tener una documentación establecida que describa los roles, las responsabilidades y las autoridades de una manera claramente definida y que esos roles se asignen adecuadamente, una organización puede garantizar que su sistema de administración de privacidad sea eficaz.

Directrices:

Esto se demostraría proporcionando la documentación establecida de la organización que describe los roles, responsabilidades y autoridades de cada persona pertinente. Los analistas de certificación revisarán esto para asegurarse de que se aborda toda la información proporcionada dentro del control.

Evidencia de ejemplo:

En las capturas de pantalla siguientes se muestran instantáneas de una directiva pim que muestra una sección de la directiva que contiene la lista de empleados aprobados.

Tenga en cuenta: La expectativa es que los ISV compartan la documentación real de procedimientos o directivas auxiliares y no simplemente proporcionen una captura de pantalla.

Control Nº 11

Proporcione pruebas de los procesos para mostrar 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 han implementado controles para la transmisión de PII, incluida cualquier confidencialidad.

• El registro de transferencia de PII de un país o región a otro existe con el consentimiento expreso para hacerlo.

Intención: PII

La intención de la minimización de PII (Información de identificación personal) es garantizar que una organización recopile, use y conserve solo la cantidad mínima de datos personales necesarios para lograr un propósito específico dentro del contexto de la organización y dentro de la justificación empresarial. Al controlar los datos personales, una organización tiene que identificar cuál es la cantidad mínima de datos necesaria para lograr ese objetivo o tarea y asegurarse de que no se almacenan más de esos datos mínimos necesarios. Al minimizar el procesamiento y el almacenamiento de datos personales innecesarios, una organización garantiza que se reduzca el nivel de riesgo asociado con el uso indebido de datos, el acceso no autorizado y las infracciones de datos.

Directrices: PII

La evidencia se puede proporcionar mediante la configuración de la solución utilizada para minimizar el uso de información personal si esto se hace a través de una plataforma automatizada o si se trata de un proceso administrativo manual, entonces se deben proporcionar al analista pruebas del proceso de minimización y evidencia de los registros del proceso que se producen para su revisión.

Evidencia de ejemplo: PII

En la captura de pantalla siguiente se muestra que se programa una reunión mensual de repetición donde se revisan todos los nuevos datos recibidos dentro de la organización dentro de ese período y, si procede, se quita cualquier información personal que se considere innecesaria.

En la captura de pantalla siguiente se muestra un ejemplo de un formulario de registro de usuario rellenado que se usa para incorporar nuevos clientes dentro de la plataforma.

En la captura de pantalla siguiente se muestra que, en función de la reunión y revisión de minimización de PII, se consideró que parte de la información confidencial recopilada en el formulario ya no es necesaria para devolver el servicio al usuario. En la siguiente imagen, se ha quitado la PII de los árbitros, así como la dirección de correo electrónico (la expectativa es que cada organización tenga una justificación empresarial para mantener o quitar esa información).

Tenga en cuenta: El anterior es un ejemplo de un escenario potencial. No es en modo alguno completo y, al proporcionar pruebas, el proceso para minimizar la PII debe demostrarse claramente y debe aplicarse al contexto específico de la organización.

Intención: privacidad de datos

La intención de este subpunto es multifacética y abarca varias técnicas y conceptos diferentes, pero el objetivo general es que una organización sea compatible con las regulaciones de protección de datos al garantizar que se mejore la privacidad de los datos en toda la organización.

A partir de la desidentificación, que es el proceso de eliminación de información específica que se puede usar para identificar a una persona de los datos, la intención es asegurarse de que cualquier información que se considere confidencial, como la dirección de correo electrónico, la fecha de nacimiento, etc., se cambie o convierta (a través de diversas técnicas como seudónimo o enmascaramiento) en un formato que hace que no se pueda usar para vincularla directamente a un individuo. El propósito de este proceso no es solo conservar la utilidad de los datos, sino también garantizar que se reduce el nivel de riesgo asociado con el uso indebido de datos, el acceso no autorizado y las infracciones de datos.

Las organizaciones deben definir la retención de datos y eliminar los datos innecesarios al final del período de procesamiento. Una vez que los datos superan el período de retención de datos definido, se deben eliminar de forma segura para asegurarse de que no se pueden reconstruir ni recuperar. Mantener los datos necesarios y durante el tiempo necesario ayuda a reducir el riesgo para la organización en caso de que se produzca una vulneración de datos. Esto garantiza que los datos no se conserven durante una duración excesivamente larga ni se eliminen prematuramente, lo que podría suponer riesgos de naturaleza variable: legales, operativos o relacionados con la seguridad.

Directrices: privacidad de los datos

La evidencia puede proporcionarse mediante la configuración del mecanismo o la técnica utilizadas para garantizar que los datos de PII se anonimicen y eliminen de acuerdo con el requisito de control.

Evidencia de ejemplo: privacidad de datos

En el ejemplo que se muestra en las capturas de pantalla siguientes se usa la plantilla de anonimización de datos integrada de Azure Data Factory, que forma parte de la Galería de plantillas y nos permite mover un conjunto de archivos de texto de una ubicación a otra mientras anonimizamos su contenido. Muestra que existe una factoría de datos en Azure para la anonimización de PII.

En la captura de pantalla siguiente se muestra la configuración de la canalización de anonimización de PII. Aprovecha el código para usar Presidio en Azure App Service para llamar a Presidio como punto de conexión REST HTTP en la canalización de Azure Data Factory mientras analiza y almacena cada archivo como un almacenamiento de blobs de Azure.

En la captura de pantalla siguiente se muestran los pasos y la lógica de la canalización.

En la captura de pantalla final se muestra una ejecución correcta de la canalización para anonimizar la PII.

Tenga en cuenta: El anterior es un ejemplo de un escenario potencial. No es en modo alguno completo y, al proporcionar pruebas, el proceso de anonimización de pii debe demostrarse claramente y debe aplicarse al contexto específico de la organización.

Evidencia de ejemplo: privacidad de datos

En la captura de pantalla siguiente se muestra un ejemplo de cómo abordar la eliminación de PII al final del período de procesamiento habilitando una directiva de administración del ciclo de vida para la cuenta de almacenamiento de Azure donde se mantiene PII.

En la captura de pantalla siguiente se muestra que la retención se establece durante un período predefinido después del cual los datos se eliminan automáticamente.

Tenga en cuenta: El anterior es un ejemplo de un escenario potencial. No es en modo alguno completo y, al proporcionar pruebas, el proceso de eliminación de datos pii y el período de retención específico aplicable deben demostrarse claramente y aplicarse al contexto específico de la organización.

Evidencia de ejemplo: privacidad de datos

En la captura de pantalla final se muestra que se ha implementado una directiva de retención de administración del ciclo de vida de datos para la transferencia y el almacenamiento de datos de PII en varias ubicaciones de la organización, como SharePoint, OneDrive, dispositivos, buzón de correo, etc. Esta directiva está habilitada mediante Microsoft Purview. La directiva de retención está configurada para eliminar automáticamente cualquier PII una vez transcurrido el período de retención predefinido.

Tenga en cuenta: El anterior es un ejemplo de un escenario potencial. No es en modo alguno completo y, al proporcionar pruebas, el proceso de eliminación de datos pii y el período de retención específico aplicable deben demostrarse claramente y aplicarse al contexto específico de la organización.

Intención: controles

La intención de este subpunto es garantizar que las organizaciones dispongan de las medidas de seguridad técnicas y administrativas/operativas adecuadas para proteger la PII durante el procesamiento y la transmisión. El énfasis en la confidencialidad se refiere a la protección de datos frente a accesos y divulgaciones no autorizados a través de controles técnicos y administrativos, como el cifrado de los datos en reposo y en tránsito, las listas de control de acceso documentadas y la auditoría regular.

Directrices: controles

Las pruebas se pueden proporcionar mediante la configuración de los mecanismos de protección utilizados para garantizar que los datos pii estén protegidos de acuerdo con el requisito de control. Estos mecanismos pueden incluir controles de acceso, RBAC, cifrado, prevención de pérdida de datos, etc.

Declinación de responsabilidades: en los ejemplos presentados se muestran algunos escenarios posibles en los que se aplican controles para garantizar que la PII está protegida. Tenga en cuenta que el tipo de mecanismos de protección implementados dependerá del contexto de su organización y de cómo se use, almacene, etc.

Evidencia de ejemplo: cifrado

En los ejemplos siguientes se muestra el cifrado de PII en la ubicación de almacenamiento donde se mantiene la PII y el cifrado durante el tránsito a través de la aplicación o plataforma web donde los usuarios introducen información personal que se almacena en el back-end de la aplicación.

Las capturas de pantalla muestran que la ubicación de almacenamiento tiene datos en reposo cifrados de forma predeterminada.

Tenga en cuenta que si la plataforma usada de forma predeterminada no realiza el cifrado y su propio cifrado

las claves están en uso, entonces la expectativa es que esas claves estén suficientemente protegidas y se proporcionen pruebas para demostrarlo.

En la segunda captura de pantalla se muestra que TLS1.2 se aplica en tránsito para la aplicación donde se recopila PII.

Evidencia de ejemplo: controles de acceso

En la captura de pantalla siguiente se muestra desde una perspectiva de red que solo el intervalo IP autorizado o aprobado que es la red corporativa segura tiene acceso a la ubicación de almacenamiento de PII.

En la captura de pantalla siguiente se muestra un ejemplo de Azure PIM y la lista de usuarios con las asignaciones aptas. Al usar el acceso Just-In-Time (JIT), permite a los usuarios obtener acceso temporal a un rol o recurso con privilegios durante un período de tiempo limitado, lo que reduce el riesgo de que un usuario con privilegios se vea comprometido o introduzca cambios en el entorno, las ubicaciones de datos, etc.

Evidencia de ejemplo: prevención de transmisión y divulgación de PII

En estas capturas de pantalla se muestra La prevención de pérdida de datos (DLP) de Microsoft Purview, que es una plataforma integrada que permite a las organizaciones administrar sus directivas DLP desde una única ubicación centralizada.

A continuación, puede observar que está habilitada una directiva de "Datos de PII del Reino Unido". Esto proporciona la capacidad de impedir que los usuarios proporcionen datos confidenciales a sitios web específicos, como correo electrónico personal, mensajes de IA generativos, sitios de redes sociales y mucho más cuando se accede a ellos a través de un explorador web compatible. Esto garantiza que el riesgo de posibles infracciones de confidencialidad o divulgaciones no autorizadas de PII por parte de los empleados se reduzca a medida que todos los dispositivos o usuarios del área de trabajo tengan aplicada la directiva de la organización.

Las capturas de pantalla siguientes proporcionan una visión general completa de la directiva, incluido el ámbito al que se aplica. La directiva se establece en todas las cuentas de ubicaciones como SharePoint, Dispositivos, OneDrive, etc.

En la captura de pantalla anterior y siguiente se muestra que la directiva DLP está establecida para evitar que los usuarios copien y peguen información confidencial, como la información de identificación personal (PII)

desde las bases de datos internas de la organización a sus cuentas de correo electrónico personales, bots de chat y sitios de redes sociales en exploradores compatibles.

Intención: registros

La intención de este subpunto es doble; garantiza que se ha implementado una gestión eficaz de los registros para facilitar la gobernanza de los datos y la protección de datos, a la vez que garantiza el cumplimiento legal y la responsabilidad, ya que la transferencia de información de identificación personal entre diferentes países implica navegar por diferentes requisitos legales. Antes de iniciar una transferencia de PII, una organización debe asegurarse de que tiene el consentimiento explícito de los interesados a los que pertenece, dichas personas deben ser informadas sobre la transferencia, el propósito de la transferencia y el riesgo asociado. El registro del consentimiento obtenido validará la autorización de la transferencia. El registro de las transferencias también debe contener detalles adicionales de la transferencia, la evaluación de riesgos, el impacto en la protección de datos y el período de retención.

Directrices: registros

Las pruebas que se pueden proporcionar para los registros de transferencias de PII y los registros de consentimiento expresado dependerán de cómo se implemente el proceso de transferencia y la administración de registros a nivel de la organización. Esto puede incluir si el consentimiento se obtiene a través de una plataforma, términos y condiciones del servicio, o a través de formularios de consentimiento rellenados por cada usuario. Las pruebas proporcionadas deben demostrar que existen registros históricos de las transferencias realizadas durante un período y cómo se realiza el seguimiento, así como registros de consentimiento explícito que se obtienen.

Evidencia de ejemplo: registros

En la captura de pantalla siguiente se muestra un ejemplo de un formulario de consentimiento rellenado por uno de los usuarios de los servicios de la organización. Podemos ver que el usuario proporcionó el consentimiento explícito, la confirmación y la comprensión de las condiciones.

En la captura de pantalla siguiente se muestra que existe un registro histórico de transferencias de PII e incluye detalles de los datos pii específicos que se intercambian, la finalidad de la transferencia, el país de origen, el país de destino, la protección de los datos en tránsito, la aprobación, etc.

Tenga en cuenta que el anterior es un ejemplo de un escenario potencial, no es en modo alguno completo y, al proporcionar pruebas, el proceso para transferir datos de PII, la administración de registros, etc. debe demostrarse claramente y debe aplicarse al contexto específico de la organización.

RGPD

La mayoría de las organizaciones procesarán datos potencialmente de un ciudadano europeo (interesados). Cuando se procesen los datos de CUALQUIER interesado, las organizaciones deberán cumplir con el Reglamento General de Protección de Datos (RGPD). Esto se aplica tanto a los controladores de datos (está capturando directamente dichos datos) como a los procesadores de datos (está procesando estos datos en nombre de un controlador de datos). Aunque esta sección no cubre toda la regulación, aborda algunos de los elementos clave del RGPD para ayudar a obtener cierta seguridad de que la organización se está tomando en serio el RGPD.

Control Nº 12

Proporcione pruebas que demuestren que:

• Los interesados pueden generar SAR.

• Valide que usted (el ISV) puede identificar todas las ubicaciones de los datos de los interesados al responder a una solicitud de SAR.

• Que hay un período de retención para las copias de seguridad que permite que los clientes que solicitan la eliminación de datos a través de SAR se quiten a medida que se quitan las copias de seguridad graduales durante un período (ciclo de vida de eliminaciones de copias de seguridad más antiguas o reescrituras).

Intención:

EL RGPD incluye obligaciones específicas que deben cumplir las organizaciones que procesan los datos de los interesados. La obligación de las organizaciones de administrar solicitudes de acceso de sujetos (SAR) se incluye en el artículo 12, que, de conformidad con el artículo 12.3, concede a un responsable de los datos un mes desde la recepción del SAR para responder a la solicitud. Se permite una extensión durante dos meses más cuando sea necesario y solo si hay justificación para hacerlo. Incluso si su organización actúa como procesador de datos, esto seguirá siendo necesario para ayudar a sus clientes (el responsable del tratamiento de datos) a cumplir sus obligaciones de SAR.

Directrices:

Proporcione el proceso documentado para controlar los SAR. Evidencia de ejemplo:

En el ejemplo siguiente se muestra un proceso documentado para el control de LAS.

Nota: En esta captura de pantalla se muestra un documento de directiva o proceso, la expectativa es que los ISV compartan la documentación real sobre directivas o procedimientos auxiliares.

Intención:

La intención de este control es asegurarse de que la organización tiene un mecanismo sólido para identificar los datos de todos los interesados. Puede tratarse de un proceso manual porque todo el almacenamiento de datos está bien documentado o se pueden usar otras herramientas para asegurarse de que todos los datos se encuentran como parte del proceso de SAR.

Directrices:

La evidencia se puede proporcionar mediante una lista de todas las ubicaciones de datos y un proceso documentado para buscar datos en todas las ubicaciones de datos. Esto incluiría los comandos necesarios para buscar datos, es decir, si se incluyen ubicaciones SQL, se detallarían instrucciones SQL específicas para asegurarse de que los datos se encuentran correctamente.

Evidencia de ejemplo:

La siguiente captura de pantalla es un fragmento de código del procedimiento de SAR anterior que muestra cómo se encontrarán los datos.

Las cuatro imágenes siguientes muestran cómo se consultaron las ubicaciones de datos de ISV y el Explorador de Storage se usó para explorar en profundidad los archivos o blobs que debían quitarse del almacenamiento para cumplir con la solicitud de SAR.

Nota: que estos ejemplos no son capturas de pantalla completa, se le pedirá que envíe capturas de pantalla completa con cualquier dirección URL, el usuario que ha iniciado sesión y la marca de fecha y hora para la revisión de pruebas. Si es un usuario de Linux, esto se puede hacer a través del símbolo del sistema.

Esta consulta confirma las cuentas de almacenamiento en uso. Puede consultar y quitar almacenamiento, blobs o archivos mediante el Explorador de Resource Graph (Kusto) o PowerShell (consulte siguiente).

Nota: - Para los ejemplos de esta sección no se usaron capturas de pantalla completas, sin embargo, todas las capturas de pantalla de pruebas enviadas por ISV deben ser capturas de pantalla completa que muestren la dirección URL, la hora y la fecha de inicio de sesión del usuario y del sistema.

En la imagen siguiente se muestran los datos que se han encontrado en el contenedor de blobs del cliente que se deben quitar y lo siguiente muestra la acción para eliminar o eliminar temporalmente la información del blob.

Tenga en cuenta: que los ejemplos no son capturas de pantalla completa, se le pedirá que envíe capturas de pantalla completa con cualquier dirección URL, el usuario que ha iniciado sesión y la marca de fecha y hora para la revisión de pruebas. Si es un usuario de Linux, esto se puede hacer a través del símbolo del sistema.

Intención:

El objetivo de este control es demostrar que existe un período de retención formal para las copias de seguridad, diseñado de forma que se adapte a la eliminación de datos de conformidad con las SAR. El marco de retención debe permitir la eliminación gradual de copias de seguridad anteriores durante un período definido, lo que garantiza que los datos eliminados debido a una SAR se borren en última instancia de todas las copias de seguridad. Esto es fundamental para alinear las prácticas de copia de seguridad y retención de datos de la organización con las obligaciones derivadas de los SAR, cumpliendo así los requisitos normativos relativos al derecho de eliminación.

Directrices:

La evidencia se puede proporcionar mediante una captura de pantalla que muestra los valores de configuración de copia de seguridad que muestran el período y la metodología con los que se realizan las copias de seguridad. El énfasis debe estar en el período de frecuencia de copia de seguridad.

Evidencia de ejemplo:

La captura de pantalla siguiente es un fragmento de código de configuración de la base de datos de Azure para MySQL, que es una instancia administrada.

Podemos ver en la captura de pantalla que el período de retención de copia de seguridad está establecido para 28 días.

En función de la sección de copia de seguridad, sabemos que las copias de seguridad en servidores flexibles se basan en instantáneas con la primera copia de seguridad de instantáneas programada inmediatamente después de crear un servidor y que se realizan más copias de seguridad de instantáneas diariamente una vez.

La retención de copia de seguridad de 28 días combinada con la frecuencia de copia de seguridad significa que, cuando se cumple un SAR, la copia de seguridad gradual continuará durante un máximo de 27 días de forma gradual y disminuye según lo exige el período de retención hasta que se quiten todos los datos del usuario.

Control Nº 13

Proporcione el aviso de privacidad que debe contener todos los elementos necesarios de la siguiente manera:

• Detalles de entidades (nombre, dirección, etc.)

• Detalles del tipo de datos personales que se están procesando.

• Detalla cuánto tiempo se conservarán los datos personales.

• Detalles de la legalidad del tratamiento de datos personales.

• Detalles de los derechos del interesado:

  • Derecho a ser informado

  • Derecho de acceso por parte del interesado

  • Derecho a borrar

  • Derecho a la restricción del procesamiento

  • Derecho a la portabilidad de datos

  • Derecho al objeto

  • Derechos en relación con la toma de decisiones automatizada, incluida la generación de perfiles

Intención:

El artículo 13 del RGPD incluye información específica que debe proporcionarse a los interesados en el momento en que se obtienen los datos personales. La intención de este control es garantizar que el aviso de privacidad de datos de las organizaciones proporciona a los interesados parte de la información clave incluida en el artículo 13.

Directrices:

Normalmente, esto se proporcionaría proporcionando el aviso de privacidad de datos. Los analistas de certificación lo revisarán para asegurarse de que toda la información proporcionada dentro del control está incluida en el aviso de privacidad de datos.

Evidencia de ejemplo:

En las capturas de pantalla siguientes se muestran instantáneas de una directiva de privacidad.

Tenga en cuenta que estos ejemplos no son capturas de pantalla completa, se le pedirá que envíe capturas de pantalla completa con cualquier dirección URL, el usuario que ha iniciado sesión y la marca de fecha y hora para la revisión de pruebas. Si es un usuario de Linux, esto se puede hacer a través del símbolo del sistema.

Las imágenes de un Aviso de privacidad muestran un ejemplo de una política de privacidad en línea con el artículo 13 del RGPD incluido.

A continuación se muestra una directiva de protección de datos que se puede usar junto con el aviso de privacidad mostrado anteriormente.

En la imagen anterior de Azure se muestra cómo se ha configurado Azure para cumplir los requisitos de cumplimiento del RGPD para los datos almacenados en un entorno back-end. La directiva (que se puede personalizar o compilar a partir de Azure Blueprints) permite al ISV asegurarse de que los datos del cliente se almacenan correctamente y de que solo las métricas especificadas pueden acceder a ellos. Además, las alertas se establecen para garantizar el cumplimiento y mostrarán los datos no conformes o el acceso de usuario en el panel del administrador de cumplimiento.

Tenga en cuenta: que los ejemplos anteriores no son capturas de pantalla completa, se le pedirá que envíe capturas de pantalla completa con cualquier dirección URL, el usuario que ha iniciado sesión y la marca de fecha y hora para la revisión de pruebas. Si es un usuario de Linux, esto se puede hacer a través del símbolo del sistema.

HIPAA (Ley de portabilidad y responsabilidad del seguro de salud)

La Ley de Portabilidad y Responsabilidad del Seguro De Salud de 1996 (HIPAA) es una legislación federal aplicable a los ciudadanos estadounidenses y a las organizaciones sanitarias. Es importante tener en cuenta que esta legislación también cubre a todas las organizaciones fuera de ee. UU. que procesan datos de atención sanitaria de ciudadanos estadounidenses. La introducción de la legislación obligaba al Secretario del Departamento de Salud y Servicios Humanos (HHS) de los Estados Unidos a elaborar regulaciones que protesen la privacidad y la seguridad de cierta información sanitaria. Algunas organizaciones pueden procesar datos que son información de salud potencialmente protegida (ePHI), lo que significa información de salud identificable individualmente transmitida por medios electrónicos, mantenida en medios electrónicos, o transmitida o mantenida en cualquier otra forma o medio. Cuando se procesen los datos de estado de CUALQUIER interesado, las organizaciones deberán cumplir con HIPAA.

HIPAA tiene dos leyes que deben tenerse en cuenta: "La regla de privacidad", o estándares para la privacidad de la información de salud identificable individualmente, que describe los estándares nacionales para la protección de cierta información de salud, y "Los estándares de seguridad" para la protección de la información de salud protegida electrónica también se conocen como la "Regla de seguridad". Esta última establece un conjunto nacional de normas de seguridad para proteger cierta información sanitaria que se mantiene o transfiere en forma electrónica.

A partir de una introducción de alto nivel, "La regla de seguridad" es una implementación práctica de las protecciones que ofrece la "Regla de privacidad". Describe las medidas técnicas y no técnicas que las "entidades cubiertas" deben implementar para garantizar la seguridad de la "información sanitaria protegida electrónica" (E-PHI) de las personas. Aunque esta sección no cubre toda la regulación, aborda algunos de los elementos clave de HIPAA para ayudar a obtener cierta seguridad de que la organización cumple con el requisito y que la organización protege la información de salud que procesa.

Control Nº 14

Proporcione pruebas demostrables de que:

• Existe una directiva para el control de HIPAA e HIPAA dentro de su organización para el personal, contratistas, etc.

• ISV garantiza la confidencialidad, integridad y disponibilidad de ePHI que crea, recibe, mantiene o transmite.

• Proteja contra cualquier amenaza y peligro razonablemente previsto para la seguridad o integridad de ePHI.

Intención:

La intención de este subpunto es asegurarse de que las organizaciones han establecido protocolos que sirven como procedimientos estándar para administrar la información sanitaria, tratar las emergencias y las interrupciones del servicio, y el acceso del personal a la información sanitaria y la formación. Además, se espera que las organizaciones mantengan y describan estas medidas de seguridad administrativas como parte de su programa de seguridad HIPAA. Este es un aspecto crucial del cumplimiento de las regulaciones hipaa.

Directrices:

Esto se demostraría proporcionando la documentación establecida de la organización que describe la directiva y el procedimiento hipaa. Los analistas de certificación revisarán esto para asegurarse de que se aborda toda la información proporcionada dentro del control.

Evidencia de ejemplo:

Las capturas de pantalla muestran instantáneas de una directiva HIPAA. Tenga en cuenta: La expectativa es que los ISV compartan la documentación real de procedimientos o directivas auxiliares y no simplemente proporcionen una captura de pantalla.

Nota: La expectativa es que un ISV comparta la documentación completa real de procedimientos o directivas auxiliares y no simplemente proporcione una captura de pantalla.

Intención:

Para comprender la intención de este subpunto y garantizar el cumplimiento con la regla de seguridad, las "entidades cubiertas" primero deben saber cómo se definen los términos de confidencialidad, integridad y disponibilidad en § 164.304:

• Confidencialidad: "la propiedad de que los datos o la información no están disponibles o divulgados a personas o procesos no autorizados".

• Integridad: "la propiedad que los datos o la información no se han modificado o destruido de forma no autorizada".

• Disponibilidad: "la propiedad de que los datos o la información son accesibles y utilizables a petición de una persona autorizada".

La intención de este requisito es que las organizaciones implementen medidas o medidas técnicas como el acceso, la auditoría, la integridad y los controles de transmisión dentro de la infraestructura de TI para garantizar la confidencialidad de ePHI y, al mismo tiempo, mantener su integridad y disponibilidad para los usuarios autorizados.

Directrices:

Las pruebas se pueden proporcionar a modo de configuración de los mecanismos de protección utilizados para garantizar que los datos de ePHI estén protegidos de acuerdo con el requisito de control. Estos mecanismos pueden incluir controles de acceso, procedimientos de acceso de emergencia, RBAC, cifrado, etc.

Evidencia de ejemplo: controles de acceso e integridad

En la captura de pantalla siguiente se muestra que existe una lista de acceso autorizado de las personas que tienen permisos para controlar las ubicaciones de almacenamiento de ePHI y se mantiene en el documento de directiva HIPAA. Además, en las capturas de pantalla siguientes a la lista de inventario aprobada, se puede observar que el acceso de escritura en el clúster es limitado, ya que solo el administrador y el analista de mantenimiento de bases de datos pueden leer y escribir en el clúster.

La siguiente captura de pantalla tomada de una de las bases de datos de almacenamiento de ePHI en Atlas Mongo muestra que solo los usuarios autorizados tienen el acceso documentado y que todas las cuentas tienen identificadores de usuario únicos para garantizar la responsabilidad.

En la primera captura de pantalla se muestra la ubicación de almacenamiento principal o el clúster de base de datos para ePHI.

En la segunda captura de pantalla se muestra que los usuarios aprobados solo tienen documentados los roles y el acceso.

Las dos capturas de pantalla siguientes muestran una vista más pormenorizada de cada uno de los roles asignados y todos los permisos asociados que están en línea con la aprobación de acceso anterior.

Cada rol personalizado tiene un conjunto de permisos y un ámbito de acceso.

Por último, la siguiente captura de pantalla muestra desde una perspectiva de red que solo el intervalo IP autorizado que es la red corporativa segura tiene acceso al clúster.

Pruebas de ejemplo: controles de auditoría

Estas capturas de pantalla muestran que el registro y las alertas se implementan para el clúster de base de datos. En la primera captura de pantalla se muestra que las alertas están habilitadas. Tenga en cuenta que la expectativa es que la evidencia proporcionada también muestre las reglas de alerta establecidas en función de la necesidad o implementación de la organización. En la segunda captura de pantalla se muestra que se está habilitando la auditoría de base de datos.

En la captura de pantalla siguiente se muestra el historial de acceso al clúster de base de datos que se está registrando. La expectativa es que las alertas se establezcan y se basen en los registros de auditoría y cualquier acceso no autorizado que no cumpla las condiciones predefinidas desencadenará una alerta.

Las dos últimas capturas de pantalla muestran que se generan registros de auditoría para el clúster de base de datos y que los registros se pueden exportar para su análisis.

Tenga en cuenta que la expectativa es que haya un proceso para que los registros de auditoría generados se analicen, también se deben proporcionar pruebas del proceso de revisión. Si esto se logra mediante programación, se deben proporcionar capturas de pantalla de la configuración de la ingesta de registros en la plataforma o solución de registro utilizada, así como capturas de pantalla de las reglas para su revisión.

Evidencia de ejemplo: controles de cifrado y transmisión

En las capturas de pantalla siguientes se muestra que la ubicación de almacenamiento tiene datos en reposo cifrados de forma predeterminada. Tenga en cuenta que si la plataforma usada de forma predeterminada no realiza el cifrado y sus propias claves de cifrado están en uso, la expectativa es que esas claves estén adecuadamente protegidas y se proporcionen pruebas para demostrarlo.

Las dos capturas de pantalla siguientes muestran que la ubicación de almacenamiento tiene datos en tránsito cifrados de forma predeterminada. En la primera captura de pantalla se muestra que una API de datos está habilitada con permisos de "lectura y escritura".

Un examen SSL del punto de conexión muestra que los datos en tránsito se cifran a través de TLS 1.2.

Evidencia de ejemplo: controles de disponibilidad y recuperación

En la captura de pantalla siguiente se muestra que el clúster de base de datos se replica en tres regiones para garantizar la disponibilidad. Mongo Atlas lo hace de forma predeterminada. Además, la copia de seguridad está habilitada y está activa.

En la captura de pantalla siguiente se muestra el panel de copia de seguridad del clúster, que también muestra que ya se ha creado una instantánea.

En las dos capturas de pantalla siguientes se muestra que se ha implementado una directiva de copia de seguridad para realizar copias de seguridad programadas en distintos momentos del tiempo (PIT).

A continuación se indica que hay una directiva de retención para las instantáneas y la restauración a un momento dado (PIT).

Intención:

La intención de este subpunto se alinea con la regla de seguridad que se desarrolló para garantizar la flexibilidad y escalabilidad para que una "entidad cubierta" pueda implementar directivas, procedimientos y soluciones tecnológicas adecuadas para el tamaño de la entidad, su estructura organizativa y sus riesgos específicos, así como su apetito por el riesgo. Desde una perspectiva práctica, esto significa que las medidas de seguridad adecuadas implementadas dependerán de la naturaleza del negocio de la "entidad cubierta", así como de su tamaño y recursos.

Es fundamental que todas las organizaciones realicen un análisis de riesgos completo para descubrir posibles riesgos y vulnerabilidades para la confidencialidad, integridad y disponibilidad de la PHI electrónica. A través de este análisis de riesgos, las organizaciones pueden implementar los controles de seguridad adecuados para mitigar estos riesgos identificados.

Directrices:

La evidencia se puede proporcionar mediante la salida del análisis de riesgos. Cuando el análisis de riesgos se realiza y se mantiene a través de una plataforma en línea, se deben proporcionar capturas de pantalla de toda la salida.

Evidencia de ejemplo:

En las capturas de pantalla siguientes se muestran instantáneas del proceso de evaluación de riesgos, seguidas del análisis de riesgos que se realizó para determinar hasta qué punto los controles se implementan correctamente y funcionan según lo previsto para proteger ePHI. En la segunda captura de pantalla se muestra un análisis de riesgos para los riesgos identificados en la evaluación de riesgos y los controles de compensación y mitigaciones implementados para reducir el nivel de riesgo.

Ejemplo 1: Instantánea del proceso de evaluación de riesgos dentro de la directiva HIPAA y el análisis de riesgos realizados

Nota: Esta captura de pantalla muestra una instantánea de un documento de análisis de riesgos, esto es solo un ejemplo, y la expectativa es que los ISV compartan la documentación real y no simplemente proporcionen una captura de pantalla.

Ejemplo 2: Capturas de pantalla del proceso de evaluación de riesgos dentro de la directiva HIPAA y el análisis de riesgos realizado (mantenido en Confluence Cloud Platform)

En la segunda captura de pantalla se muestra un análisis de riesgos para los riesgos identificados en la evaluación de riesgos y los controles de compensación y mitigaciones implementados para reducir el nivel de riesgo. Podemos ver que esto existe y se mantiene en la plataforma en la nube de Confluence.

Control Nº 15

Proporcione pruebas de que usted (ISV):

• Protege contra los usos o divulgaciones razonablemente previstos de dicha información que no están permitidos por la Regla de privacidad; y

• Garantizar el cumplimiento de la regla de seguridad por parte de su personal.

• Plan de copia de seguridad de datos y recuperación ante desastres en 164...308 (a)(7)(ii)(A) y 164.308 (a)(7)(ii)(B).

Intent

La Regla de privacidad define qué fragmentos de información de salud protegida (PHI) están cubiertos por la ley y prohíbe los usos y divulgaciones inadecuados de la PHI. La intención de este subpunto es que una organización debe limitar el acceso y el uso de la phi-electrónica solo a aquellos que lo necesiten con fines autorizados y que deben cumplir con la regla mínima necesaria, que les obliga a usar o revelar solo la cantidad mínima de phis electrónicos necesaria para lograr su propósito previsto.

Debe existir una combinación de medidas de seguridad técnicas y administrativas para restringir el uso de ePHI y garantizar que se reduzca el riesgo de divulgación del ePHI.

Directrices:

Las pruebas proporcionadas deben mostrar las medidas de seguridad técnicas vigentes, como las tecnologías y los mecanismos que están en uso para proteger la PHI electrónica y cómo la organización controla el acceso y el movimiento de dichos datos.

Evidencia de ejemplo:

En las capturas de pantalla siguientes se muestra La prevención de pérdida de datos (DLP) de Microsoft Purview, que es una plataforma integrada que permite a las organizaciones administrar sus directivas DLP desde una única ubicación centralizada.

A continuación, puede observar que está habilitada una directiva "Mejorada por HIPAA de EE. UU.". Esto proporciona la capacidad de impedir que los usuarios peguen datos confidenciales en sitios web específicos, como correo electrónico personal, mensajes de IA generativos, sitios de redes sociales y mucho más cuando se accede a ellos a través de un explorador web compatible.

En la siguiente captura de pantalla se proporciona una información general más completa de la directiva, incluido el ámbito al que se aplica. La directiva se establece en todas las cuentas de ubicaciones como SharePoint, Dispositivos, OneDrive, etc.

Al seleccionar la opción "Editar directiva", se muestra una vista más detallada de las configuraciones específicas disponibles.

Las dos capturas de pantalla siguientes muestran la definición de contenido y las condiciones que se deben cumplir para que se aplique la directiva.

La directiva abarca varios tipos de datos confidenciales, así como un conjunto de clasificadores.

En la sección siguiente se muestran las acciones configuradas para realizarse cuando se cumplen las condiciones mostradas en las capturas de pantalla anteriores.

En la captura de pantalla siguiente se muestra que la directiva DLP está establecida para impedir que sus usuarios copien y peguen información confidencial, como información de identificación personal (PII) de las bases de datos internas de la organización en sus cuentas de correo electrónico personales, bots de chat y sitios de redes sociales en exploradores compatibles.

Por último, las notificaciones de usuario están configuradas para notificar y proporcionar instrucciones a los usuarios a medida que controlan los datos de ePHI.

En la captura de pantalla siguiente se muestra el panel de configuración para generar alertas cuando se produce un incidente.

Intención:

La intención de este subpunto es que una organización debe entrenar a su personal sobre cómo controlar la phis electrónica de forma segura y adecuada, y que deben aplicar directivas y procedimientos para garantizar el cumplimiento de la regla de seguridad.

Directrices:

Las pruebas proporcionadas deben demostrar que el entrenamiento hipaa se lleva a cabo sobre cómo controlar ePHI y que existen registros de asistencia y finalización del entrenamiento. Cuando corresponda, esto puede ser compatible con la documentación de directivas y los materiales de aprendizaje utilizados.

Evidencia de ejemplo:

En los ejemplos siguientes se muestran las posibles pruebas que se pueden enviar para demostrar que el entrenamiento de HIPAA adecuado se produce en consonancia con la directiva.

En la captura de pantalla siguiente se muestra una instantánea de la directiva HIPAA con una sección específica que describe el requisito de entrenamiento. Tenga en cuenta que esto es solo un ejemplo y no un documento o implementación completos, la expectativa es que el ISV tenga un proceso establecido que se aplique a su organización.

Ejemplo 1: Entrenamiento de usuarios hipaa mediante proceso administrativo

En la siguiente captura de pantalla, la diapositiva de información general del curso muestra un resumen de los objetivos del curso. Si el entrenamiento está integrado en la casa, los materiales de entrenamiento deben ser suministrados para su revisión, tenga en cuenta que el material completo debe ser enviado y no sólo una captura de pantalla del resumen.

En la captura de pantalla siguiente se muestra el registro de asistencia de los empleados que participaron en el entrenamiento. El registro también muestra la puntuación de pase, así como la siguiente fecha programada de entrenamiento.

En el segundo ejemplo se muestra cómo se puede usar Microsoft 365 Defender para establecer e iniciar campañas de entrenamiento.

Ejemplo 2: entrenamiento de usuarios hipaa a través de la Plataforma de simulación de ataques de Microsoft 365 Defender (todos los usuarios)

En la captura de pantalla anterior se muestra la campaña de entrenamiento de seguridad HIPAA, la duración total en minutos, así como el estado de finalización. En la captura de pantalla siguiente se proporciona información general sobre los usuarios a los que se asignó el entrenamiento y el estado del entrenamiento, que muestra la finalización correcta.

Ejemplo 3: Entrenamiento de usuarios hipaa a través de la Plataforma de simulación de ataques de Microsoft 365 Defender (usuario individual)

Aunque el ejemplo anterior se centró en demostrar que todos los usuarios completaron la campaña de entrenamiento anual, el ejemplo final muestra pruebas dirigidas que muestran la finalización de un empleado.

Puede observar en las dos capturas de pantalla anteriores que, en cuanto se inició la campaña de entrenamiento, cada empleado recibió un correo electrónico que confirma la asignación de entrenamiento y la fecha de vencimiento, así como los módulos asignados, la duración, etc.

Con el vínculo disponible en la notificación por correo electrónico, en la siguiente captura de pantalla se muestra la página Asignaciones de entrenamiento para el usuario y los dos módulos que ya se han completado.

Intención:

Según la Regla de seguridad hipaa, un plan de copia de seguridad de datos y un plan de recuperación ante desastres son obligatorios para cualquier "entidad cubierta" que controle la información de salud protegida electrónica (ePHI). Estos planes forman parte de la estrategia de contingencia que tiene como objetivo garantizar la disponibilidad y la seguridad de ePHI en caso de emergencia u otra ocurrencia que dañe los sistemas que contienen ePHI.

La intención del plan de copia de seguridad de datos es crear y mantener copias idénticas recuperables de ePHI; esto también debe incluir pruebas periódicas de las copias de seguridad para garantizar que la recuperación de datos sea posible. La intención del plan de recuperación ante desastres es restaurar los posibles datos perdidos en caso de desastre y esto debe especificar los pasos que se deben seguir para restaurar el acceso a los datos, incluido cómo se deben restaurar los archivos a partir de copias de seguridad.

Directrices:

Proporcione la versión completa del plan o procedimiento de recuperación ante desastres que debe cubrir el plan de copia de seguridad y el plan de recuperación. Proporcione el documento PDF/Word real si se encuentra en una versión digital, como alternativa, si el proceso se mantiene a través de una plataforma en línea, proporcione una exportación pdf o si no puede exportarse debido a limitaciones de la plataforma, proporcione capturas de pantalla que cubran toda la política.

Evidencia de ejemplo:

En la siguiente captura de pantalla se muestran instantáneas de la directiva de seguridad HIPAA que contienen información general sobre el procedimiento de copia de seguridad general y de alto nivel y el plan de recuperación ante desastres.

Nota: Esta captura de pantalla muestra una instantánea del documento de directiva o proceso, esto es solo un ejemplo, y la expectativa es que los ISV compartan la documentación completa real de procedimientos o directivas auxiliares y no simplemente proporcionen una captura de pantalla.

Libros

Murdoch D. (2018) Blue Team Handbook: Incident Response Edition: A condensed field guide for the Cyber Security Incident Responding Responder. 2nd Edition, Publisher: CreateSpace Independent Publishing Platform.

Referencias

• Informes de ciberdelincuencia de fraudes de acción disponibles en: https://www.actionfraud.police.uk/ (Acceso: 12/10/2023).

• UE. (2021) Lista de comprobación del RGPD para los controladores de datos Disponible en: https://gdpr.eu/checklist/ (Accessed: 12/10/2023).

• Microsoft. (2018) Registro de eventos (Windows Installer) Disponible en: Registro de eventos (al que se accede: 03/05/2024).

• Tecnologías positivas. (2020) Enfoque del desarrollo seguro de software Disponible en: https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/(Accessed:12/10/2023).

• Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de dichos datos, y por la que se deroga la Directiva 95/46/CE (Reglamento General de Protección de Datos) (Texto pertinente para el EEE) (2016) disponible en: https://www.legislation.gov.uk/eur/2016/679/contents (Accessed: 12/10/2023).

• Métricas de seguridad. (2020) Guía de métricas de seguridad para el cumplimiento de PCI DSS. Disponible en: https://info.securitymetrics.com/pci-guide-2020(Accesible: 12/10/2023).

• Clasificación de riesgo de Williams J. OWASP disponible en: https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (Accessed: 12/10/2023).

• Qualys. (2014) LABORATORIOS SSL: Nuevos grados de confianza (T) y problemas de discrepancia (M) disponibles en: https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-no coincidente-m-issues (accessed: 12/10/2023).

• NIST SP800-61r2: Computer Security Incident Handling Guide Available at: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final (Accessed: 12/10/2023).

• Creación de una canalización de CI/CD con Azure Pipelines y Google Kubernetes Engine | .NET

• Google Cloud (a la que se accede: 10/10/2023).

• El plan de recuperación ante desastres en: https://www.sans.org/white-papers/1164/ (Accesible: 10/10/2023).

• https://github.com/ (Acceso: 10/10/23).

• Plantillas de directiva de seguridad en: https://www.sans.org/information-security-policy/ (Acceso: 10/10/23).

• https://www.openedr.com/ (Acceso: 02/10/23).

• https://www.atlassian.com/software/confluence (Acceso: 10/10/23).

• https://www.atlassian.com/software/jira (Acceso el 28/09/23).

• Plantilla de ejercicio superior de tabla del plan de continuidad empresarial (BCP) en: https://www.pivotpointsecurity.com/services/business-continuity-management/table-top-exercise-template/ (Accessed: 10/10/23).

• Resumen de la regla de seguridad hipaa | HHS.gov (accedido: 18/10/2023).

• Leyes de privacidad de la información de salud en la era digital: HIPAA no se aplica - PMC (nih.gov) (a la que se accede: 18/10/2023).

• ¿Cuál es el propósito de HIPAA? Actualización 2023 (hipaajournal.com) (Acceso: 18/10/2023).

• ¿Qué se considera PHI en HIPAA? Actualización de 2023 (hipaajournal.com) (Acceso: 18/10/2023).

• Directivas y procedimientos hipaa (hipaajournal.com) (acceso: 18/10/2023).

• Diseño de directivas HIPAA & directivas administrativas | Dash Solutions (dashsdk.com) (Accessed: 18/10/2023).

• 45 CFR § 164.304 - Definiciones. | Código electrónico de regulaciones federales (e-CFR) | Ley de EE. UU. | LII

• / Instituto de Información Legal (cornell.edu) (Acceso: 18/10/2023).

• ¿Qué es el cumplimiento de HIPAA? Leyes hipaa & reglas | Proofpoint UK (Acceso: 18/10/2023).

• Reglas, reglamentos y estándares de seguridad hipaa (training-hipaa.net) (acceso: 18/10/2023).

• Resumen de la regla de seguridad hipaa | HHS.gov (accedido: 18/10/2023).

• SP 800-66 Rev. 1, An Introductory Resource Guide for Implementing the Health InsurancePortability and Accountability Act (HIPAA) Security Rule | CSRC (nist.gov) (acceso: 18/10/2023).

• La regla de seguridad | HHS.gov (a la que se accede: 18/10/2023).

• https://www.hipaajournal.com/hipaa-encryption-requirements (Acceso: 19/10/2023).

• https://www.hipaajournal.com/hipaa-privacy-rule/ (Acceso: 19/10/2023).

• https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html (Acceso: 19/10/2023).

• https://www.restore.co.uk/Records/Services/Magnetic-Tape-Storage (Acceso: 19/10/2023).

• https://www.tausight.com/the-ultimate-guide-to-electronic-protected-health-information- ephi/ (Accedido: 19/10/2023).

• Configurar cifrado : manual de MongoDB (accesible: 19/10/2023).

• https://its.ucsc.edu/policies/docs/hipaa-risk-analysis.doc (Acceso: 19/10/2023).

• Prevención de pérdida de datos de Microsoft Purview: anuncio de la disponibilidad general de varias funcionalidades

• Microsoft Community Hub (accesible: 10/24/2023).

• 45 CFR § 164.308 - Medidas de seguridad administrativas. | Código electrónico de regulaciones federales (e-CFR)

• | Ley de EE. UU. | LII /Legal Information Institute> (cornell.edu) (Acceso: 24/10/2023).

• https://www.iow.nhs.uk/Downloads/Policies/Business%20Continuity%20Policy.pdf (Acceso: 10/24/2023).

• ¿Cuándo debemos proporcionar información de privacidad? | ICO (Acceso: 11/08/2023).

• ¿Cómo debemos redactar nuestra información de privacidad? | ICO (Acceso: 11/08/2023).

• Marco de responsabilidad | ICO (a la que se accede: 11/08/2023).

• Requisito 5.1 de LA ISO 27001: Compromiso de liderazgo & | ISMS.online (acceso: 08/11/2023).

• Plataforma de navegación en línea (OBP) (iso.org) (a la que se accede: 11/08/2023).

• Cláusula 5.3 Roles organizativos, responsabilidades y autoridades - Formación iso (a la que se accede: 08/11/2023).

• 5.3 Roles, Responsabilidad y Autoridad (iso9001help.co.uk) (Acceso: 08/11/2023).

• Principio (c): Minimización de datos | ICO (a la que se accede: 11/08/2023).

• Desidentificación y reidentificación de PII en conjuntos de datos a gran escala mediante la protección de datos confidenciales| Centro de arquitectura en la nube | Google Cloud (a la que se accede: 11/08/2023).

• Desidentición de datos confidenciales | Documentación de protección de datos confidenciales | Google Cloud (a la que se accede: 11/08/2023).

• Guía de seguridad de datos | ICO (a la que se accede: 11/08/2023).

• Transferencias de datos internacionales | ICO (a la que se accede: 11/08/2023).

• Administración y seguridad de registros | ICO (a la que se accede: 11/08/2023).

• ISO 27701 - Administración de la información de privacidad (a la que se accede: 08/11/2023).

• Iso 27701 Privacy Information Management System (PIMS) | ISMS.Online (accessed: 08/11/2023).

Imágenes o texto tomados de documentos de Microsoft

• https://www.sans.org/information-security-policy/ (Acceso: 18/02/21).

• Obtenga análisis de comportamiento y detección de anomalías (accessed:03/05/24).

• ¿Qué son las alertas de Azure Monitor? (A la que se accede:03/05/24).

• Obtención de análisis de comportamiento y detección de anomalías

• (A la que se accede:03/05/24).

• Administrar y responder a alertas de seguridad en Microsoft Defender for Cloud (accessed:03/05/24).

• Administrar y responder a alertas de seguridad en Microsoft Defender for Cloud (accessed:03/05/24).

• https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html (Acceso: 10/09/23).

• ¿Qué es Azure Information Protection?

• Cifrado de datos transparente para SQL Database, SQL Managed Instance y Azure Synapse Analytics (accessed:03/05/24).

• Inicio rápido: Creación de una asignación de directiva para identificar recursos no compatibles (Accessed:03/05/24).

• Configuración de Advanced Threat Protection para Azure SQL Database (accessed:03/05/24).

• Copia de seguridad y restauración en Azure Database for MySQL: servidor flexible (accesible:03/05/24).

• Inventario de certificados (accedido:03/05/24).

• Copia de seguridad y restauración en Azure Database for MySQL (accessed:03/05/24).

• https://github.com/microsoft/presidio/blob/main/docs/samples/deployments/data- factory/presidio-data-factory-template-gallery-http.md (accessed: 08/11/2023).

Más información

• Guía de pruebas de ejemplo: información general
• Guía de pruebas de ejemplo: Operaciones