Dominio de seguridad: seguridad operativa
El dominio de seguridad operativo garantiza que los ISV implementan un conjunto sólido de técnicas de mitigación de seguridad frente a una gran variedad de amenazas a las que se enfrentan los actores de amenazas. Esto está diseñado para proteger el entorno operativo y los procesos de desarrollo de software para crear entornos seguros.
Aprendizaje de concienciación
La formación en reconocimiento de la seguridad es importante para las organizaciones, ya que ayuda a minimizar los riesgos derivados de errores humanos, que están implicados en más del 90 % de las infracciones de seguridad. Ayuda a los empleados a comprender la importancia de las medidas y procedimientos de seguridad. Cuando se ofrece formación de reconocimiento de seguridad, refuerza la importancia de una cultura consciente de la seguridad en la que los usuarios saben reconocer y responder a posibles amenazas. Un programa de aprendizaje de reconocimiento de seguridad eficaz debe incluir contenido que abarque una amplia gama de temas y amenazas a los que pueden enfrentarse los usuarios, como la ingeniería social, la administración de contraseñas, la privacidad y la seguridad física.
Control Nº 1
Proporcione pruebas de que:
La organización proporciona formación de reconocimiento de seguridad establecida a los usuarios del sistema de información (incluidos administradores, ejecutivos sénior y contratistas):
Como parte del entrenamiento inicial para nuevos usuarios.
Cuando sea necesario por los cambios del sistema de información.
Frecuencia de formación de reconocimiento definida por la organización.
Documenta y supervisa las actividades individuales de reconocimiento de seguridad del sistema de información y conserva los registros de entrenamiento individuales a través de una frecuencia definida por la organización.
Intención: entrenamiento para nuevos usuarios
Este subpunto se centra en establecer un programa obligatorio de formación de reconocimiento de seguridad diseñado para todos los empleados y para los nuevos empleados que se unen a la organización, independientemente de su rol. Esto incluye administradores, ejecutivos sénior y contratistas. El programa de reconocimiento de seguridad debe abarcar un plan de estudios completo diseñado para impartir conocimientos básicos sobre los protocolos, directivas y procedimientos recomendados de seguridad de la información de la organización para garantizar que todos los miembros de la organización estén alineados con un conjunto unificado de estándares de seguridad, lo que crea un entorno de seguridad de la información resistente.
Directrices: entrenamiento para nuevos usuarios
La mayoría de las organizaciones usarán una combinación de aprendizaje de reconocimiento de seguridad basado en plataforma y documentación administrativa, como documentación de directivas y registros, para realizar un seguimiento de la finalización de la formación para todos los empleados de toda la organización. Las pruebas proporcionadas deben mostrar que los empleados han completado el entrenamiento, y se debe hacer una copia de seguridad con directivas o procedimientos de apoyo que describa el requisito de reconocimiento de seguridad.
Prueba de ejemplo: entrenamiento para nuevos usuarios
En la captura de pantalla siguiente se muestra la plataforma de Confluence que se usa para realizar un seguimiento de la incorporación de nuevos empleados. Se ha generado un vale JIRA para el nuevo empleado, incluida su asignación, rol, departamento, etc. Con el nuevo proceso de inicio, la formación de reconocimiento de seguridad ha sido seleccionada y asignada al empleado que debe completarse antes de la fecha de vencimiento del28 de febrero de 2023.
En la captura de pantalla se muestra el certificado de finalización generado por Knowb4 tras la finalización correcta del entrenamiento de reconocimiento de seguridad por parte del empleado. La fecha de finalización es el21 de febrero de 2023, que se encuentra dentro del período asignado.
Intención: cambios en el sistema de información.
El objetivo de este subpunto es garantizar que se inicie el entrenamiento de reconocimiento de seguridad adaptable siempre que haya cambios significativos en los sistemas de información de la organización. Las modificaciones podrían surgir debido a actualizaciones de software, cambios en la arquitectura o nuevos requisitos normativos. La sesión de entrenamiento actualizada garantiza que todos los empleados estén informados sobre los nuevos cambios y el impacto resultante en las medidas de seguridad, lo que les permite adaptar sus acciones y decisiones en consecuencia. Este enfoque proactivo es vital para proteger los recursos digitales de la organización frente a vulnerabilidades que podrían surgir de los cambios del sistema.
Directrices: cambios en el sistema de información.
La mayoría de las organizaciones usarán una combinación de formación de reconocimiento de seguridad basada en plataformas y documentación administrativa, como documentación de directivas y registros, para realizar un seguimiento de la finalización de la formación para todos los empleados. Las pruebas proporcionadas deben demostrar que varios empleados han completado el entrenamiento en función de diferentes cambios en los sistemas de la organización.
Evidencia de ejemplo: cambios en el sistema de información.
En las capturas de pantalla siguientes se muestra la asignación de formación de reconocimiento de seguridad a varios empleados y se muestra que se producen simulaciones de suplantación de identidad (phishing).
La plataforma se usa para asignar un nuevo entrenamiento cada vez que se produce un cambio del sistema o se produce un error en una prueba.
Intención: frecuencia de entrenamiento de reconocimiento.
El objetivo de este subpunto es definir una frecuencia específica de la organización para el entrenamiento periódico de reconocimiento de seguridad. Esto podría programarse anualmente, semestralmente o en un intervalo diferente determinado por la organización. Al establecer una frecuencia, la organización garantiza que los usuarios se actualicen periódicamente en el panorama en constante evolución de las amenazas, así como en las nuevas medidas y directivas de protección. Este enfoque puede ayudar a mantener un alto nivel de reconocimiento de seguridad entre todos los usuarios y a reforzar los componentes de entrenamiento anteriores.
Directrices: frecuencia de entrenamiento de concienciación.
La mayoría de las organizaciones tendrán documentación administrativa o una solución técnica para describir o implementar el requisito y el procedimiento para la formación de reconocimiento de seguridad, así como definir la frecuencia de la formación. Las pruebas proporcionadas deben demostrar la realización de diversas capacitaciones de reconocimiento dentro del período definido y que existe un período definido por su organización.
Evidencia de ejemplo: frecuencia de entrenamiento de reconocimiento.
En las capturas de pantalla siguientes se muestran instantáneas de la documentación de la directiva de reconocimiento de seguridad y que existe y se mantiene. La directiva requiere que todos los empleados de la organización reciban formación de reconocimiento de seguridad como se describe en la sección de ámbito de la directiva. El departamento correspondiente debe asignar y completar la formación anualmente.
Según el documento de política, todos los empleados de la organización deben completar tres cursos (una formación y dos evaluaciones) anualmente y dentro de los veinte días posteriores a la asignación. Los cursos deben enviarse por correo electrónico y asignarse a través de KnowBe4.
El ejemplo proporcionado solo muestra instantáneas de la directiva; tenga en cuenta que la expectativa es que se envíe el documento de directiva completo.
La segunda captura de pantalla es la continuación de la directiva y muestra la sección del documento que exige el requisito de formación anual, y muestra que la frecuencia definida por la organización de la formación de reconocimiento se establece en anualmente.
Las dos capturas de pantalla siguientes muestran la finalización correcta de las evaluaciones de entrenamiento mencionadas anteriormente. Las capturas de pantalla se tomaron de dos empleados diferentes.
Intención: documentación y supervisión.
El objetivo de este subpunto es crear, mantener y supervisar registros meticulosos de la participación de cada usuario en la formación de reconocimiento de seguridad. Estos registros deben conservarse durante un período definido por la organización. Esta documentación sirve como un seguimiento auditable para el cumplimiento de las normativas y las directivas internas. El componente de supervisión permite a la organización evaluar la eficacia de la
capacitación, identificación de áreas para mejorar y comprender los niveles de interacción del usuario. Al conservar estos registros durante un período definido, la organización puede realizar un seguimiento de la eficacia y el cumplimiento a largo plazo.
Directrices: documentación y supervisión.
Las pruebas que se pueden proporcionar para el entrenamiento de reconocimiento de seguridad dependerán de cómo se implemente el entrenamiento en el nivel de la organización. Esto puede incluir si el entrenamiento se realiza a través de una plataforma o se realiza internamente en función de un proceso interno. Las pruebas proporcionadas deben mostrar que existen registros históricos de entrenamiento completado para todos los usuarios durante un período y cómo se realiza el seguimiento.
Evidencia de ejemplo: documentación y supervisión.
En la siguiente captura de pantalla se muestra el registro de entrenamiento histórico de cada usuario, incluida su fecha de unión, la finalización del entrenamiento y cuándo se programa el siguiente entrenamiento. La evaluación de este documento se realiza periódicamente y al menos una vez al año para garantizar que los registros de formación de reconocimiento de seguridad de cada empleado se mantengan actualizados.
Protección contra malware/antimalware
El malware supone un riesgo significativo para las organizaciones que pueden variar el impacto de seguridad causado en el entorno operativo, en función de las características de malware. Los actores de amenazas se han dado cuenta de que el malware puede monetizarse correctamente, lo que se ha realizado a través del crecimiento de ataques de malware de estilo ransomware. El malware también se puede usar para proporcionar un punto de entrada para que un actor de amenazas ponga en peligro un entorno para robar datos confidenciales, es decir, troyanos de acceso remoto o rootkits. Por lo tanto, las organizaciones deben implementar mecanismos adecuados para protegerse frente a estas amenazas. Las defensas que se pueden usar son antivirus (AV)/Detección y respuesta de puntos de conexión (EDR)/Respuesta de detección y protección de puntos de conexión (EDPR)/análisis basado en heurística mediante inteligencia artificial (IA). Si ha implementado una técnica diferente para mitigar el riesgo de malware, informe al analista de certificación quién estará encantado de explorar si cumple la intención o no.
Control Nº 2
Proporcione pruebas de que la solución antimalware está activa y habilitada en todos los componentes del sistema muestreados y configurada para cumplir los criterios siguientes:
si el antivirus está habilitado para el examen de acceso y las firmas están actualizadas en un plazo de 1 día.
antivirus que bloquea automáticamente malware o alertas y cuarentenas cuando se detecta malware
O si EDR/EDPR/NGAV:
que se está realizando el examen periódico.
está generando registros de auditoría.
se mantiene actualizado continuamente y tiene capacidades de aprendizaje automático.
bloquea el malware conocido e identifica y bloquea nuevas variantes de malware basadas en comportamientos de macro, así como tener capacidades de concesión completa.
Intención: examen en el acceso
Este subpunto está diseñado para comprobar que el software antimalware está instalado en todos los componentes del sistema muestreados y está realizando activamente el examen a través del acceso. El control también exige que la base de datos de firmas de la solución antimalware esté actualizada dentro de un período de tiempo de un día. Una base de datos de firmas actualizada es fundamental para identificar y mitigar las amenazas de malware más recientes, lo que garantiza que los componentes del sistema estén protegidos adecuadamente.
Directrices: análisis en el acceso**.**
Para demostrar que una instancia activa de AV se ejecuta en el entorno evaluado, proporcione una captura de pantalla para cada dispositivo del conjunto de ejemplo acordado con el analista que admite el uso de antimalware. La captura de pantalla debe mostrar que el antimalware se está ejecutando y que el software antimalware está activo. Si hay una consola de administración centralizada para el antimalware, se pueden proporcionar pruebas de la consola de administración. Además, asegúrese de proporcionar una captura de pantalla que muestra que los dispositivos muestreados están conectados y funcionando.
Prueba de ejemplo: examen a acceso**.**
La captura de pantalla siguiente se ha tomado de un dispositivo Windows Server, que muestra que "Microsoft Defender" está habilitado para el nombre de host "IaaS-Web-app".
La siguiente captura de pantalla se ha realizado desde un dispositivo Windows Server, en la que se muestra que la versión de inteligencia de seguridad antimalware de Microsoft Defender ha actualizado el registro desde el visor de eventos de Windows. Esto muestra las firmas más recientes para el nombre de host "IaaS-Web-app".
Esta captura de pantalla se ha realizado desde un dispositivo Windows Server, en la que se muestran las actualizaciones de protección antimalware de Microsoft Defender. Esto muestra claramente las versiones de definición de amenazas, la versión creada en y la última actualización para demostrar que las definiciones de malware están actualizadas para el nombre de host "IaaS-Web- app".
Intención: bloques antimalware.
El propósito de este subpunto es confirmar que el software antimalware está configurado para bloquear automáticamente el malware tras la detección o generar alertas y mover el malware detectado a un área de cuarentena segura. Esto puede garantizar que se realicen acciones inmediatas cuando se detecta una amenaza, lo que reduce la ventana de vulnerabilidad y mantiene una posición de seguridad fuerte del sistema.
Directrices: bloques antimalware.
Proporcione una captura de pantalla para cada dispositivo del ejemplo que admita el uso de antimalware. La captura de pantalla debe mostrar que el antimalware se está ejecutando y está configurado para bloquear automáticamente el malware, la alerta o la cuarentena y la alerta.
Evidencia de ejemplo: bloques antimalware.
En la captura de pantalla siguiente se muestra que el host "IaaS-Web-app" está configurado con protección en tiempo real como ON para Microsoft Defender Antimalware. Como indica la configuración, esto localiza y evita que el malware se instale o se ejecute en el dispositivo.
Intención: EDR/NGAV
Este subpunto tiene como objetivo comprobar que la detección y respuesta de puntos de conexión (EDR) o el Antivirus de próxima generación (NGAV) están realizando exámenes periódicos activamente en todos los componentes del sistema muestreados; los registros de auditoría se generan para realizar el seguimiento de las actividades de examen y los resultados; la solución de análisis se actualiza continuamente y posee capacidades de autoaprendizaje para adaptarse a los nuevos paisajes de amenazas.
Directrices: EDR/NGAV
Proporcione una captura de pantalla de la solución EDR/NGAV que muestra que todos los agentes de los sistemas muestreados informan y muestran que su estado está activo.
Evidencia de ejemplo: EDR/NGAV
En la siguiente captura de pantalla de la solución OpenEDR se muestra que un agente para el host "IaaS-Web-app" está activo e informando.
La siguiente captura de pantalla de la solución OpenEDR muestra que el examen en tiempo real está habilitado.
En la captura de pantalla siguiente se muestra que las alertas se generan en función de las métricas de comportamiento que se han obtenido en tiempo real del agente instalado en el nivel del sistema.
En las capturas de pantalla siguientes de la solución OpenEDR se muestra la configuración y generación de registros de auditoría y alertas. La segunda imagen muestra que la directiva está habilitada y que los eventos están configurados.
La siguiente captura de pantalla de la solución OpenEDR muestra que la solución se mantiene actualizada continuamente.
Intención: EDR/NGAV
El objetivo de este subpunto es asegurarse de que EDR/NGAV tienen la capacidad de bloquear automáticamente el malware conocido e identificar y bloquear nuevas variantes de malware basadas en comportamientos de macro. También garantiza que la solución tenga capacidades de aprobación completa, lo que permite a la organización permitir software de confianza mientras bloquea todo lo demás, lo que agrega una capa adicional de seguridad.
Directrices: EDR/NGAV
En función del tipo de solución utilizada, se pueden proporcionar pruebas que muestren la configuración de la solución y que la solución tenga capacidades de aprendizaje automático o heurística, así como que se configure para bloquear el malware tras la detección. Si la configuración se implementa de forma predeterminada en la solución, la documentación del proveedor debe validarla.
Evidencia de ejemplo: EDR/NGAV
En las capturas de pantalla siguientes de la solución OpenEDR se muestra que un perfil seguro v7.4 está configurado para aplicar el examen en tiempo real, bloquear el malware y poner en cuarentena.
En las capturas de pantalla siguientes de la configuración de Perfil seguro v7.4 se muestra que la solución implementa el examen "En tiempo real" en función de un enfoque antimalware más tradicional, que examina las firmas de malware conocidas, y el examen de "Heurística" establecido en un nivel medio. La solución detecta y quita malware comprobando los archivos y el código que se comportan de forma sospechosa, inesperada o malintencionada.
El analizador está configurado para descomprimir los archivos y examinar los archivos dentro para detectar posibles malware que podrían enmascararse en el archivo, además, el analizador está configurado para bloquear micro scripts dentro de los archivos de Microsoft Office.
En las capturas de pantalla siguientes se muestra que el perfil seguro v.7.4 se ha asignado a nuestro host "IaaS-Web-app" del dispositivo Windows Server.
La siguiente captura de pantalla se realizó desde el dispositivo de Windows Server "IaaS-Web-app", que demostró que el agente de OpenEDR está habilitado y en ejecución en el host.
Protección contra malware/control de aplicaciones
El control de aplicaciones es una práctica de seguridad que bloquea o restringe la ejecución de aplicaciones no autorizadas de maneras que ponen en riesgo los datos. Los controles de aplicación son una parte importante de un programa de seguridad corporativo y pueden ayudar a evitar que actores malintencionados aprovechen las vulnerabilidades de la aplicación y reduzcan el riesgo de una infracción. Al implementar el control de aplicaciones, las empresas y las organizaciones pueden reducir en gran medida los riesgos y amenazas asociados con el uso de la aplicación, ya que las aplicaciones no se pueden ejecutar si ponen en riesgo la red o los datos confidenciales. Los controles de aplicación proporcionan a los equipos de operaciones y seguridad un enfoque confiable, estandarizado y sistemático para mitigar el riesgo cibernético. También proporcionan a las organizaciones una imagen más completa de las aplicaciones en su entorno, lo que puede ayudar a las organizaciones de TI y seguridad a administrar eficazmente el riesgo cibernético.
Control Nº 3
Proporcione pruebas que demuestren lo siguiente:
Tiene una lista aprobada de software o aplicaciones con justificación empresarial:
existe y se mantiene actualizado, y
que cada aplicación se somete a un proceso de aprobación y cierre la sesión antes de su implementación.
Esa tecnología de control de aplicaciones está activa, habilitada y configurada en todos los componentes del sistema muestreados, como se documenta.
Intención: lista de software
Este subpunto tiene como objetivo asegurarse de que existe una lista aprobada de software y aplicaciones dentro de la organización y se mantiene actualizada continuamente. Asegúrese de que cada software o aplicación de la lista tiene una justificación empresarial documentada para validar su necesidad. Esta lista sirve como referencia autoritativa para regular la implementación de software y aplicaciones, lo que ayuda a eliminar software no autorizado o redundante que podría suponer un riesgo para la seguridad.
Directrices: lista de software
Documento que contiene la lista aprobada de software y aplicaciones si se mantiene como documento digital (Word, PDF, etc.). Si la lista aprobada de software y aplicaciones se mantiene a través de una plataforma, se deben proporcionar capturas de pantalla de la lista de la plataforma.
Evidencia de ejemplo: lista de software
En las capturas de pantalla siguientes se muestra que se mantiene una lista de aplicaciones y software aprobados en la plataforma de Confluence Cloud.
En las capturas de pantalla siguientes se muestra que se mantiene la lista de aplicaciones y software aprobados, incluido el solicitante, la fecha de solicitud, el aprobador, la fecha de aprobación, el mecanismo de control, el vale JIRA, el sistema o el recurso.
Intención: aprobación de software
El propósito de este subpunto es confirmar que cada software o aplicación se somete a un proceso de aprobación formal antes de su implementación dentro de la organización. El proceso de aprobación debe incluir una evaluación técnica y un cierre de sesión ejecutivo, lo que garantiza que se hayan tenido en cuenta las perspectivas operativas y estratégicas. Al instituir este riguroso proceso, la organización garantiza que solo se implemente el software revisado y necesario, minimizando así las vulnerabilidades de seguridad y garantizando la alineación con los objetivos empresariales.
Instrucciones
Se pueden proporcionar pruebas que muestren que se está siguiendo el proceso de aprobación. Esto se puede proporcionar mediante documentos firmados, el seguimiento dentro de los sistemas de control de cambios o el uso de algo como Azure DevOps/JIRA para realizar un seguimiento de las solicitudes de cambio y la autorización.
Pruebas de ejemplo
En las capturas de pantalla siguientes se muestra un proceso de aprobación completo en JIRA Software. Un usuario "Jane Doe" ha generado una solicitud para que se instale "Allow Qualys Cloud Agent" en los servidores "IaaS-Web-app" y "IaaS-VM- Backend". 'Andrew Smith' ha revisado la solicitud y la ha aprobado con el comentario 'aprobado en función de la necesidad empresarial de antimalware. Actualizaciones y revisiones proporcionadas por Qualys. Software que se va a aprobar."
En la siguiente captura de pantalla se muestra la aprobación que se concede a través del vale generado en la plataforma de Confluence antes de permitir que la aplicación se ejecute en el servidor de producción.
Intención: tecnología de control de aplicaciones
Este subpunto se centra en comprobar que la tecnología de control de aplicaciones está activa, habilitada y configurada correctamente en todos los componentes del sistema muestreados. Asegúrese de que la tecnología funciona de acuerdo con las directivas y procedimientos documentados, que sirven como directrices para su implementación y mantenimiento. Al tener una tecnología de control de aplicaciones activa, habilitada y bien configurada, la organización puede ayudar a evitar la ejecución de software no autorizado o malintencionado y mejorar la posición de seguridad general del sistema.
Directrices: tecnología de control de aplicaciones
Proporcione documentación que detalla cómo se ha configurado el control de aplicaciones y pruebas de la tecnología aplicable que muestra cómo se ha configurado cada aplicación o proceso.
Evidencia de ejemplo: tecnología de control de aplicaciones
En las capturas de pantalla siguientes se muestra que las directivas de grupo (GPO) de Windows están configuradas para aplicar solo el software y las aplicaciones aprobados.
En la captura de pantalla siguiente se muestra el software o las aplicaciones que se pueden ejecutar a través del control de ruta de acceso.
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 completa que muestren cualquier dirección URL, el usuario que ha iniciado sesión y la hora y la fecha del sistema.
Administración de revisiones, aplicación de revisiones y clasificación de riesgos
La administración de revisiones, a menudo denominada aplicación de revisiones, es un componente crítico de cualquier estrategia sólida de ciberseguridad. Implica el proceso sistemático de identificación, prueba y aplicación de revisiones o actualizaciones de software, sistemas operativos y aplicaciones. El objetivo principal de la administración de revisiones es mitigar las vulnerabilidades de seguridad, lo que garantiza que los sistemas y el software sigan siendo resistentes frente a posibles amenazas. Además, la administración de revisiones abarca la clasificación de riesgos como elemento fundamental para priorizar las revisiones. Esto implica evaluar las vulnerabilidades en función de su gravedad y el posible impacto en la posición de seguridad de una organización. Mediante la asignación de puntuaciones de riesgo a vulnerabilidades, las organizaciones pueden asignar recursos de forma eficaz, centrando sus esfuerzos en abordar rápidamente las vulnerabilidades críticas y de alto riesgo, al tiempo que mantienen una postura proactiva frente a las amenazas emergentes. Una estrategia eficaz de administración de revisiones y clasificación de riesgos no solo mejora la seguridad, sino que también contribuye a la estabilidad general y al rendimiento de la infraestructura de TI, lo que ayuda a las organizaciones a mantenerse resistentes en el panorama en constante evolución de las amenazas de ciberseguridad.
Para mantener un entorno operativo seguro, las aplicaciones o complementos y los sistemas auxiliares se deben aplicar revisiones adecuadamente. Es necesario administrar un período de tiempo adecuado entre la identificación (o la versión pública) y la aplicación de revisiones para reducir la ventana de oportunidad para que un actor de amenazas aproveche una vulnerabilidad. La certificación de Microsoft 365 no estipula una "ventana de aplicación de revisiones"; sin embargo, los analistas de certificación rechazarán los períodos de tiempo que no son razonables o están en consonancia con los procedimientos recomendados del sector. Este grupo de control de seguridad también está en el ámbito de los entornos de hospedaje de plataforma como servicio (PaaS), ya que las bibliotecas de software y la base de código de terceros de aplicación o complemento deben aplicar revisiones en función de la clasificación de riesgos.
Control Nº 4
Proporcione pruebas de que la directiva de administración de revisiones y la documentación de procedimientos definen lo siguiente:
Una ventana de aplicación de revisiones mínima adecuada para vulnerabilidades de riesgo crítico/alto y medio.
Retirada de sistemas operativos y software no admitidos.
Cómo se identifican y asignan una puntuación de riesgo a las nuevas vulnerabilidades de seguridad.
Intención: administración de revisiones
La administración de revisiones es necesaria para muchos marcos de cumplimiento de seguridad, como PCI-DSS, ISO 27001, NIST (SP) 800-53, FedRAMP y SOC 2. La importancia de una buena administración de revisiones no se puede sobrecargar
ya que puede corregir problemas de seguridad y funcionalidad en software, firmware y mitigar vulnerabilidades, lo que ayuda a reducir las oportunidades de explotación. La intención de este control es minimizar la ventana de oportunidad que tiene un actor de amenaza para aprovechar las vulnerabilidades que pueden existir en el entorno dentro del ámbito.
Proporcione una directiva de administración de revisiones y documentación de procedimientos que abarcó exhaustivamente los siguientes aspectos:
Una ventana de aplicación de revisiones mínima adecuada para vulnerabilidades de riesgo crítico/alto y medio.
La documentación de procedimientos y directivas de administración de revisiones de la organización debe definir claramente una ventana de aplicación de revisiones mínima adecuada para las vulnerabilidades clasificadas como riesgos críticos/altos y medianos. Dicha disposición establece el tiempo máximo permitido dentro del cual se deben aplicar revisiones después de la identificación de una vulnerabilidad, en función de su nivel de riesgo. Al indicar explícitamente estos intervalos de tiempo, la organización normalizó su enfoque de administración de revisiones, minimizando el riesgo asociado a vulnerabilidades sin parches.
Retirada de sistemas operativos y software no admitidos.
La directiva de administración de revisiones incluye disposiciones para el retirada de software y sistemas operativos no admitidos. Los sistemas operativos y el software que ya no reciben actualizaciones de seguridad suponen un riesgo significativo para la posición de seguridad de una organización. Por lo tanto, este control garantiza que dichos sistemas se identifican y quitan o reemplazan de forma oportuna, tal como se define en la documentación de la directiva.
- Procedimiento documentado que describe cómo se identifican y asignan nuevas vulnerabilidades de seguridad a una puntuación de riesgo.
La aplicación de revisiones debe basarse en el riesgo, cuanto más arriesgada sea la vulnerabilidad, más rápido debe corregirse. La clasificación de riesgos de las vulnerabilidades identificadas es una parte integral de este proceso. La intención de este control es asegurarse de que hay un proceso de clasificación de riesgos documentado que se sigue para asegurarse de que todas las vulnerabilidades identificadas se clasifican adecuadamente en función del riesgo. Las organizaciones suelen usar la clasificación del sistema de puntuación de vulnerabilidades comunes (CVSS) proporcionada por proveedores o investigadores de seguridad. Se recomienda que, si las organizaciones dependen de CVSS, se incluya un mecanismo de nueva clasificación dentro del proceso para permitir que la organización cambie la clasificación en función de una evaluación interna de riesgos. A veces, es posible que la vulnerabilidad no sea aplicable debido a la forma en que la aplicación se ha implementado en el entorno. Por ejemplo, se puede liberar una vulnerabilidad de Java que afecta a una biblioteca específica que no usa la organización.
Nota: Incluso si se ejecuta en un entorno puramente de plataforma como servicio "PaaS/sin servidor", todavía tiene la responsabilidad de identificar vulnerabilidades dentro de la base de código: es decir, bibliotecas de terceros.
Directrices: administración de revisiones
Proporcione el documento de directiva. Se deben proporcionar pruebas administrativas, como la documentación de directivas y procedimientos, en la que se detallan los procesos definidos de la organización que cubren todos los elementos del control especificado.
Nota: esa evidencia lógica se puede proporcionar como evidencia auxiliar que proporcionará información adicional sobre el Programa de administración de vulnerabilidades (VMP) de su organización, pero no cumplirá este control por sí solo.
Evidencia de ejemplo: administración de revisiones
En la captura de pantalla siguiente se muestra un fragmento de código de una directiva de clasificación de riesgos y administración de revisiones, así como los distintos niveles de categorías de riesgo. A esto le siguen los períodos de tiempo de clasificación y corrección. 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.
Ejemplo de (opcional) pruebas técnicas adicionales que respaldan el documento de directiva
Pruebas lógicas como hojas de cálculo de seguimiento de vulnerabilidades, informes de evaluación técnica de vulnerabilidades o capturas de pantalla de incidencias generadas a través de plataformas de administración en línea para realizar un seguimiento del estado y el progreso de las vulnerabilidades usadas para respaldar la implementación del proceso descrito en la documentación de directiva que se va a proporcionar. En la siguiente captura de pantalla se muestra que Snyk, que es una herramienta de análisis de composición de software (SCA), se usa para examinar la base de código en busca de vulnerabilidades. Esto va seguido de una notificación por correo electrónico.
Nota: En este ejemplo no se usó una captura de pantalla completa, pero todas las capturas de pantalla de pruebas enviadas por ISV deben ser capturas de pantalla completas que muestren cualquier dirección URL, el usuario que ha iniciado sesión y la hora y la fecha del sistema.
Las dos capturas de pantalla siguientes muestran un ejemplo de la notificación por correo electrónico recibida cuando Snyk marca nuevas vulnerabilidades. Podemos ver que el correo electrónico contiene el proyecto afectado y el usuario asignado para recibir las alertas.
En la captura de pantalla siguiente se muestran las vulnerabilidades identificadas.
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.
Pruebas de ejemplo
En las capturas de pantalla siguientes se muestran las herramientas de seguridad de GitHub configuradas y habilitadas para buscar vulnerabilidades dentro de la base de código y las alertas se envían por correo electrónico.
La notificación por correo electrónico que se muestra a continuación es una confirmación de que los problemas marcados se resolverán automáticamente a través de una solicitud de incorporación de cambios.
Pruebas de ejemplo
En la siguiente captura de pantalla se muestra la evaluación técnica interna y la clasificación de vulnerabilidades a través de una hoja de cálculo.
Pruebas de ejemplo
En las capturas de pantalla siguientes se muestran los vales generados en DevOps para cada vulnerabilidad detectada.
La evaluación, clasificación y revisión por parte de un empleado independiente se produce antes de implementar los cambios.
Control Nº 5
Proporcione pruebas demostrables de que:
Se están aplicando revisiones a todos los componentes del sistema muestreados.
Proporcione pruebas demostrables de que los sistemas operativos no admitidos y los componentes de software no están en uso.
Intención: componentes del sistema muestreados
Este subpunto tiene como objetivo garantizar que se proporcionen pruebas verificables para confirmar que todos los componentes del sistema muestreados dentro de la organización se están aplicando revisiones activamente. Las pruebas pueden incluir, entre otros, registros de administración de revisiones, informes de auditoría del sistema o procedimientos documentados que muestran que se han aplicado revisiones. Cuando se emplea la tecnología sin servidor o plataforma como servicio (PaaS), esto debe extenderse para incluir la base de código para confirmar que las versiones más recientes y seguras de bibliotecas y dependencias están en uso.
Directrices: componentes del sistema muestreados
Proporcione una captura de pantalla para todos los dispositivos del ejemplo y componentes de software auxiliares que muestren que las revisiones se instalan de acuerdo con el proceso de aplicación de revisiones documentado. Además, proporcione capturas de pantalla que muestran la aplicación de revisiones del código base.
Evidencia de ejemplo: componentes del sistema muestreados
En la siguiente captura de pantalla se muestra la aplicación de revisiones de una máquina virtual del sistema operativo Linux "IaaS- VM-Backend".
Pruebas de ejemplo
En la siguiente captura de pantalla se muestra la aplicación de revisiones de una máquina virtual del sistema operativo Windows "IaaS-Web-app".
Pruebas de ejemplo
Si mantiene la aplicación de revisiones desde cualquier otra herramienta, como Microsoft Intune, Defender for Cloud, etc., se pueden proporcionar capturas de pantalla desde estas herramientas. En las capturas de pantalla siguientes de la solución OpenEDR se muestra que la administración de revisiones se realiza a través del portal de OpenEDR.
En la siguiente captura de pantalla se muestra que la administración de revisiones del servidor en el ámbito se realiza a través de la plataforma OpenEDR. La clasificación y el estado son visibles a continuación, lo que muestra que se produce la aplicación de revisiones.
En la captura de pantalla siguiente se muestra que los registros se generan para las revisiones instaladas correctamente en el servidor.
Pruebas de ejemplo
En la siguiente captura de pantalla se muestra que las dependencias de la biblioteca de código base o de terceros se aplican a través de Azure DevOps.
En la siguiente captura de pantalla se muestra que se confirma una corrección de las vulnerabilidades detectadas por Snyk en la rama para resolver las bibliotecas obsoletas.
En la siguiente captura de pantalla se muestra que las bibliotecas se han actualizado a las versiones admitidas.
Pruebas de ejemplo
En las capturas de pantalla siguientes se muestra que la aplicación de revisiones base de código se mantiene a través de GitHub Dependabot. Los elementos cerrados muestran que se produce la aplicación de revisiones y que se han resuelto vulnerabilidades.
Intención: sistema operativo no compatible
El software que no están siendo mantenidos por los proveedores sufrirá, con horas extra, vulnerabilidades conocidas que no son fijas. Por lo tanto, el uso de sistemas operativos y componentes de software no admitidos no se debe usar en entornos de producción. Cuando se implementa infraestructura como servicio (IaaS), el requisito de este subpunto se expande para incluir tanto la infraestructura como la base de código para asegurarse de que cada capa de la pila de tecnología es compatible con la directiva de la organización sobre el uso de software compatible.
Directrices: sistema operativo no compatible
Proporcione una captura de pantalla para todos los dispositivos del conjunto de ejemplo elegido por el analista para que pueda recopilar pruebas en contra de mostrar la versión del sistema operativo en ejecución (incluya el nombre del dispositivo o servidor en la captura de pantalla). Además de esto, proporcione pruebas de que los componentes de software que se ejecutan en el entorno ejecutan versiones compatibles del software. Esto se puede hacer proporcionando la salida de informes de examen de vulnerabilidades internos (siempre que se incluya el examen autenticado) o la salida de herramientas que comprueben bibliotecas de terceros, como Snyk, Trivy o NPM Audit. Si se ejecuta en PaaS, solo es necesario cubrir la aplicación de revisiones de bibliotecas de terceros.
Evidencia de ejemplo: sistema operativo no compatible
En la siguiente captura de pantalla de la auditoría NPM de Azure DevOps se muestra que no se usan bibliotecas o dependencias no admitidas dentro de la aplicación web.
Nota: En el siguiente ejemplo no se usó una captura de pantalla completa, 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.
Pruebas de ejemplo
En la siguiente captura de pantalla de GitHub Dependabot se muestra que no se usan bibliotecas ni dependencias dentro de la aplicación web.
Pruebas de ejemplo
La siguiente captura de pantalla del inventario de software para el sistema operativo Windows a través de OpenEDR muestra que no se encontró ningún sistema operativo y versiones de software no compatibles o obsoletos.
Pruebas de ejemplo
La siguiente captura de pantalla es de OpenEDR en el resumen del sistema operativo que muestra Windows Server 2019 Datacenter (x64) y el historial de versiones completas del sistema operativo, incluido service pack, versión de compilación, etc. validar que no se encontró ningún sistema operativo no compatible.
Pruebas de ejemplo
En la siguiente captura de pantalla de un servidor de sistema operativo Linux se muestran todos los detalles de la versión, incluidos el identificador del distribuidor, la descripción, la versión y el nombre de código, que validan que no se encontró ningún sistema operativo Linux no compatible.
Evidencia de ejemplo:
En la siguiente captura de pantalla del informe de examen de vulnerabilidades de Nessus se muestra que no se encontró ningún sistema operativo (SO) y software no admitidos en el equipo de destino.
Nota: En los ejemplos anteriores no se usó una captura de pantalla completa, 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.
Detección de vulnerabilidades
El examen de vulnerabilidades busca posibles puntos débiles en el sistema informático, las redes y las aplicaciones web de una organización para identificar agujeros que podrían dar lugar a infracciones de seguridad y a la exposición de datos confidenciales. El examen de vulnerabilidades suele ser necesario para los estándares del sector y las regulaciones gubernamentales, por ejemplo, PCI DSS (Estándar de seguridad de datos del sector de tarjetas de pago).
Un informe de Métrica de seguridad titulado "2020 Security Metrics Guide to PCI DSS Compliance" (Guía de métricas de seguridad de 2020 para el cumplimiento de PCI DSS) indica que ,en promedio, se tardaron 166 días desde el momento en que se vio que una organización tenía vulnerabilidades para que un atacante ponera en peligro el sistema. Una vez en peligro, los atacantes tenían acceso a datos confidenciales durante un promedio de 127 días, por lo que este control tiene como objetivo identificar posibles debilidades de seguridad dentro del entorno dentro del ámbito.
Mediante la introducción de evaluaciones de vulnerabilidades periódicas, las organizaciones pueden detectar debilidades e inseguridades dentro de sus entornos, lo que puede proporcionar un punto de entrada para que un actor malintencionado ponga en peligro el entorno. El examen de vulnerabilidades puede ayudar a identificar las revisiones o configuraciones incorrectas que faltan en el entorno. Mediante la realización periódica de estos exámenes, una organización puede proporcionar la corrección adecuada para minimizar el riesgo de un riesgo debido a problemas que suelen detectar estas herramientas de análisis de vulnerabilidades.
Control Nº 6
Proporcione pruebas que demuestren lo siguiente:
Se lleva a cabo el examen trimestral de vulnerabilidades de la infraestructura y las aplicaciones web.
El examen debe realizarse en toda la superficie pública (DIRECCIONES/DIRECCIONES URL) e intervalos IP internos si el entorno es IaaS, híbrido o local.
Nota: Esto debe incluir el ámbito completo del entorno.
Intención: examen de vulnerabilidades
Este control tiene como objetivo garantizar que la organización realice el examen de vulnerabilidades trimestralmente, dirigido tanto a su infraestructura como a las aplicaciones web. El examen debe ser completo, abarcando tanto las superficies públicas como las direcciones IP públicas y las direcciones URL, así como los intervalos IP internos. El ámbito del examen varía en función de la naturaleza de la infraestructura de la organización:
Si una organización implementa modelos híbridos, locales o de infraestructura como servicio (IaaS), el examen debe abarcar tanto direcciones IP públicas externas como intervalos IP internos.
Si una organización implementa plataforma como servicio (PaaS), el examen debe abarcar solo direcciones IP o direcciones URL públicas externas.
Este control también exige que el examen incluya todo el ámbito del entorno, lo que no deja ningún componente desactivado. El objetivo es identificar y evaluar vulnerabilidades en todas las partes de la pila de tecnología de la organización para garantizar una seguridad completa.
Directrices: examen de vulnerabilidades
Proporcione los informes de examen completos de los exámenes de vulnerabilidades de cada trimestre que se han realizado en los últimos 12 meses. Los informes deben indicar claramente los destinos para validar que se incluye la superficie pública completa y, si procede, cada subred interna. Proporcione todos los informes de examen para cada trimestre.
Evidencia de ejemplo: examen de vulnerabilidades
En la captura de pantalla siguiente se muestra una detección de red y un examen de puertos realizado a través de Nmap en la infraestructura externa para identificar los puertos abiertos no seguros.
Nota: No se puede usar Nmap por sí solo para cumplir con este control, ya que la expectativa es que se debe proporcionar un examen completo de vulnerabilidades. La detección de puertos de Nmap forma parte del proceso de administración de vulnerabilidades ejemplificado a continuación y se complementa con exámenes de OpenVAS y OWASP ZAP en la infraestructura externa.
En la captura de pantalla se muestra el examen de vulnerabilidades a través de OpenVAS en la infraestructura externa para identificar las configuraciones incorrectas y las vulnerabilidades pendientes.
En la captura de pantalla siguiente se muestra el informe de examen de vulnerabilidades de OWASP ZAP que muestra pruebas dinámicas de seguridad de aplicaciones.
Evidencia de ejemplo: examen de vulnerabilidades
En las capturas de pantalla siguientes del informe de examen de vulnerabilidades de Nessus Essentials tenable se muestra que se realiza el examen interno de la infraestructura.
En las capturas de pantalla anteriores se muestra la configuración de carpetas para los exámenes trimestrales en las máquinas virtuales host.
Las capturas de pantalla anteriores y siguientes muestran la salida del informe de examen de vulnerabilidades.
En la captura de pantalla siguiente se muestra la continuación del informe que cubre todos los problemas encontrados.
Control Nº 7
Proporcione pruebas de nuevo análisis que demuestren lo siguiente:
- La corrección de todas las vulnerabilidades identificadas en control 6 se aplica a la aplicación de revisiones en línea con la ventana de aplicación de revisiones mínima definida en la directiva.
Intención: aplicación de revisiones
Si no se identifican, administran y corrigen rápidamente vulnerabilidades y configuraciones incorrectas, el riesgo de que una organización se vea comprometida puede provocar posibles infracciones de datos. La identificación y corrección correctas de problemas se considera importante para la posición de seguridad general y el entorno de una organización que está en consonancia con los procedimientos recomendados de varios marcos de seguridad, por ejemplo, ISO 27001 y PCI DSS.
La intención de este control es asegurarse de que la organización proporciona pruebas creíbles de los análisis, lo que demuestra que se han corregido todas las vulnerabilidades identificadas en un control 6. La corrección debe alinearse con la ventana de aplicación de revisiones mínima definida en la directiva de administración de revisiones de la organización.
Directrices: aplicación de revisiones
Proporcione informes de nuevo examen que validen que las vulnerabilidades identificadas en el control 6 se han corregido en línea con las ventanas de aplicación de revisiones definidas en el control 4 .
Evidencia de ejemplo: aplicación de revisiones
En la siguiente captura de pantalla se muestra un examen de Nessus del entorno en el ámbito (una sola máquina en este ejemplo denominada Thor) que muestra vulnerabilidadesel 2de agosto de 2023.
En la captura de pantalla siguiente se muestra que los problemas se resolvieron, 2 días después, que se encuentra dentro de la ventana de aplicación de revisiones definida dentro de la directiva de aplicación de revisiones.
Nota: En los ejemplos anteriores no se usó una captura de pantalla completa, pero se envió TODO EL ISV.
las capturas de pantalla de evidencia deben ser capturas de pantalla completas que muestren cualquier dirección URL, el usuario que ha iniciado sesión y la hora y la fecha del sistema.
Controles de seguridad de red (NSC)
Los controles de seguridad de red son un componente esencial de marcos de ciberseguridad como ISO 27001, controles CIS y NIST Cybersecurity Framework. Ayudan a las organizaciones a administrar los riesgos asociados a las ciberamenazas, proteger los datos confidenciales del acceso no autorizado, cumplir los requisitos normativos, detectar y responder a las ciberamenazas de forma oportuna y garantizar la continuidad empresarial. La seguridad de red eficaz protege los recursos de la organización frente a una amplia gama de amenazas desde dentro o fuera de la organización.
Control Nº 8
Proporcione pruebas demostrables de que:
- Los controles de seguridad de red (NSC) se instalan en el límite del entorno dentro del ámbito y se instalan entre la red perimetral y las redes internas.
Y si es híbrido, local, IaaS también proporciona pruebas de que:
- Todo el acceso público finaliza en la red perimetral.
Intención: NSC
Este control tiene como objetivo confirmar que los controles de seguridad de red (NSC) están instalados en ubicaciones clave dentro de la topología de red de la organización. En concreto, los NSC deben colocarse en el límite del entorno dentro del ámbito y entre la red perimetral y las redes internas. La intención de este control es confirmar que estos mecanismos de seguridad están correctamente situados para maximizar su eficacia en la protección de los recursos digitales de la organización.
Directrices: NSC
Se deben proporcionar pruebas para demostrar que los controles de seguridad de red (NSC) están instalados en el límite y configurados entre redes perimetrales e internas. Esto se puede lograr proporcionando las capturas de pantalla de la configuración de los controles de seguridad de red (NSC) y el ámbito al que se aplica, por ejemplo, un firewall o una tecnología equivalente, como grupos de seguridad de red (NSG) de Azure, Azure Front Door, etc.
Evidencia de ejemplo: NSC
La siguiente captura de pantalla es de la aplicación web "PaaS-web-app"; La hoja redes muestra que todo el tráfico entrante pasa a través de Azure Front Door, mientras que todo el tráfico de la aplicación a otros recursos de Azure se enruta y filtra a través del grupo de seguridad de red de Azure a través de la integración de red virtual.
Las reglas de denegación dentro de las "restricciones de acceso" impiden cualquier entrada excepto desde Front Door (FD), el tráfico se enruta a través de FD antes de llegar a la aplicación.
Evidencia de ejemplo: NSC
En la captura de pantalla siguiente se muestra la ruta predeterminada de Azure Front Door y que el tráfico se enruta a través de Front Door antes de llegar a la aplicación. También se ha aplicado la directiva waf.
Evidencia de ejemplo: NSC
En la primera captura de pantalla se muestra un grupo de seguridad de red de Azure aplicado en el nivel de red virtual para filtrar el tráfico entrante y saliente. En la segunda captura de pantalla se muestra que SQL Server no se puede enrutar a través de Internet y se integra a través de la red virtual y a través de un vínculo privado.
Esto garantiza que el NSG filtre el tráfico interno y la comunicación antes de llegar al servidor SQL Server.
Intent**:** hybrid, on-prem, IaaS
Este subpunto es esencial para las organizaciones que operan modelos híbridos, locales o de infraestructura como servicio (IaaS). Su objetivo es garantizar que todo el acceso público finalice en la red perimetral, lo que es fundamental para controlar los puntos de entrada en la red interna y reducir la posible exposición a amenazas externas. Las pruebas de cumplimiento pueden incluir configuraciones de firewall, listas de control de acceso a la red u otra documentación similar que pueda justificar la afirmación de que el acceso público no se extiende más allá de la red perimetral.
Prueba de ejemplo: híbrido, local, IaaS
En la captura de pantalla se muestra que SQL Server no se puede enrutar a través de Internet y que se integra a través de la red virtual y a través de un vínculo privado. Esto garantiza que solo se permite el tráfico interno.
Prueba de ejemplo: híbrido, local, IaaS
En las capturas de pantalla siguientes se muestra que la segmentación de red está en su lugar dentro de la red virtual dentro del ámbito. La red virtual como se muestra a continuación se divide en tres subredes, cada una con un grupo de seguridad de red aplicado.
La subred pública actúa como red perimetral. Todo el tráfico público se enruta a través de esta subred y se filtra a través del grupo de seguridad de red con reglas específicas y solo se permite el tráfico definido explícitamente. El back-end consta de la subred privada sin acceso público. Todo el acceso a la máquina virtual solo se permite a través del host bastión, que tiene su propio grupo de seguridad de red aplicado en el nivel de subred.
En la captura de pantalla siguiente se muestra que el tráfico se permite desde Internet a una dirección IP específica solo en el puerto 443. Además, RDP solo se permite desde el intervalo IP de Bastion a la red virtual.
En la captura de pantalla siguiente se muestra que el back-end no se puede enrutar a través de Internet (esto se debe a que no hay ninguna dirección IP pública para la NIC) y que el tráfico solo puede originarse desde la red virtual y Bastion.
En la captura de pantalla se muestra que el host de Azure Bastion se usa para acceder a las máquinas virtuales solo con fines de mantenimiento.
Control Nº 9
Todos los controles de seguridad de red (NSC) están configurados para quitar el tráfico no definido explícitamente dentro de la base de reglas.
Las revisiones de reglas de controles de seguridad de red (NSC) se realizan al menos cada 6 meses.
Intención: NSC
Este subpunto garantiza que todos los controles de seguridad de red (NSC) de una organización estén configurados para quitar cualquier tráfico de red que no esté definido explícitamente dentro de su base de reglas. El objetivo es aplicar el principio de privilegios mínimos en la capa de red al permitir solo el tráfico autorizado mientras se bloquea todo el tráfico no especificado o potencialmente malintencionado.
Directrices: NSC
La evidencia proporcionada para esto podría ser configuraciones de reglas que muestran las reglas de entrada y donde estas reglas se terminan; ya sea mediante el enrutamiento de direcciones IP públicas a los recursos o proporcionando la NAT (traducción de direcciones de red) del tráfico entrante.
Evidencia de ejemplo: NSC
En la captura de pantalla se muestra la configuración del grupo de seguridad de red, incluido el conjunto de reglas predeterminado y una regla Deny:All personalizada para restablecer todas las reglas predeterminadas del grupo de seguridad de red y asegurarse de que todo el tráfico está prohibido. En las reglas personalizadas adicionales, la regla Deny:All define explícitamente el tráfico permitido.
Evidencia de ejemplo: NSC
En las capturas de pantalla siguientes se muestra que Azure Front Door está implementado, todo el tráfico se enruta a través de Front Door. Se aplica una directiva de WAF en "Modo de prevención" que filtra el tráfico entrante para posibles cargas malintencionadas y la bloquea.
Intención: NSC
Sin revisiones periódicas, los controles de seguridad de red (NSC) pueden quedar obsoletos e ineficaces, lo que deja a una organización vulnerable a los ciberataques. Esto puede dar lugar a infracciones de datos, robo de información confidencial y otros incidentes de ciberseguridad. Las revisiones periódicas de NSC son esenciales para administrar riesgos, proteger datos confidenciales, cumplir con los requisitos normativos, detectar y responder a ciberamenazas de forma oportuna y garantizar la continuidad empresarial. Este subpunto requiere que los controles de seguridad de red (NSC) se sometan a revisiones base de reglas al menos cada seis meses. Las revisiones periódicas son fundamentales para mantener la eficacia y la relevancia de las configuraciones de NSC, especialmente en entornos de red que cambian dinámicamente.
Directrices: NSC
Cualquier evidencia proporcionada debe poder demostrar que se han producido reuniones de revisión de reglas. Esto se puede hacer compartiendo los minutos de reunión de la revisión de NSC y cualquier evidencia adicional de control de cambios que muestre las acciones realizadas en la revisión. Asegúrese de que las fechas están presentes, ya que el analista de certificación que revisa su envío tendría que ver un mínimo de dos de estos documentos de revisión de reuniones (es decir, cada seis meses).
Evidencia de ejemplo: NSC
En estas capturas de pantalla se muestra que existen revisiones de firewall semes mensuales y que los detalles se mantienen en la plataforma de Confluence Cloud.
En la captura de pantalla siguiente se muestra que cada revisión de reglas tiene una página creada en Confluence. La revisión de reglas contiene una lista de conjuntos de reglas aprobada que describe el tráfico permitido, el número de puerto, el protocolo, etc., junto con la justificación empresarial.
Evidencia de ejemplo: NSC
En la captura de pantalla siguiente se muestra un ejemplo alternativo de revisión de reglas de seis meses que se mantiene en DevOps.
Evidencia de ejemplo: NSC
En esta captura de pantalla se muestra un ejemplo de una revisión de reglas que se realiza y se registra como una incidencia en DevOps.
En la captura de pantalla anterior se muestra la lista de reglas documentadas establecida junto con la justificación empresarial, mientras que la siguiente imagen muestra una instantánea de las reglas dentro del vale del sistema real.
Cambiar control
Un proceso de control de cambios establecido y entendido es esencial para garantizar que todos los cambios pasan por un proceso estructurado que es repetible. Al garantizar que todos los cambios pasan por un proceso estructurado, las organizaciones pueden asegurarse de que los cambios se administran de forma eficaz, se revisan por igual y se prueban adecuadamente antes de que se firmen. Esto no solo ayuda a minimizar el riesgo de interrupciones del sistema, sino que también ayuda a minimizar el riesgo de posibles incidentes de seguridad a través de cambios incorrectos que se introducen.
Control Nº 10
Proporcione pruebas que demuestren lo siguiente:
Los cambios introducidos en los entornos de producción se implementan a través de solicitudes de cambio documentadas que contienen:
impacto del cambio.
detalles de los procedimientos de retroceso.
pruebas que se van a realizar.
revisión y aprobación por parte del personal autorizado.
Intención: control de cambios
La intención de este control es asegurarse de que los cambios solicitados se hayan considerado y documentado cuidadosamente. Esto incluye evaluar el impacto del cambio en la seguridad del sistema o entorno, documentar los procedimientos de retroceso para ayudar en la recuperación si algo sale mal y detallar las pruebas necesarias para validar el éxito del cambio.
Deben implementarse procesos que prohíban que los cambios se realicen sin autorización y cierre de sesión adecuados. El cambio debe autorizarse antes de implementarse y el cambio debe firmarse una vez completado. Esto garantiza que las solicitudes de cambio se hayan revisado correctamente y que alguien de la autoridad haya firmado el cambio.
Directrices: control de cambios
La evidencia se puede proporcionar al compartir capturas de pantalla de un ejemplo de solicitudes de cambio que muestran que los detalles del impacto del cambio, los procedimientos de retroceso y las pruebas se mantienen dentro de la solicitud de cambio.
Evidencia de ejemplo: control de cambios
En la captura de pantalla siguiente se muestra una nueva vulnerabilidad de scripting entre sitios (XSS) asignada y un documento para la solicitud de cambio. Los vales siguientes muestran la información que se ha establecido o agregado al billete en su recorrido para que se resuelva.
Los dos vales siguientes muestran el impacto del cambio en el sistema y los procedimientos de retroceso que pueden ser necesarios en caso de un problema. El impacto de los cambios y los procedimientos de retroceso han pasado por un proceso de aprobación y se han aprobado para las pruebas.
En la captura de pantalla siguiente, se han aprobado las pruebas de los cambios y, a la derecha, verá que los cambios se han aprobado y probado.
A lo largo del proceso, tenga en cuenta que la persona que realiza el trabajo, la persona que informa sobre él y la persona que aprueba el trabajo que se va a realizar son personas diferentes.
El vale siguiente muestra que los cambios ya se han aprobado para la implementación en el entorno de producción. En el cuadro derecho se muestra que la prueba funcionó y se realizó correctamente y que los cambios se han implementado ahora en el entorno de Prod.
Pruebas de ejemplo
En las capturas de pantalla siguientes se muestra un vale jira de ejemplo que muestra que el cambio debe autorizarse antes de que alguien distinto del desarrollador o solicitante lo implemente y apruebe. Los cambios los aprueba alguien con autoridad. La derecha de la captura de pantalla muestra que DP ha firmado el cambio una vez completado.
En el vale siguiente al cambio se ha cerrado una vez completado y se muestra el trabajo completado y cerrado.
Nota: - En estos ejemplos no se usó una captura de pantalla completa, pero todas las capturas de pantalla de pruebas enviadas por ISV deben ser capturas de pantalla completas que muestren cualquier dirección URL, el usuario que ha iniciado sesión y la hora y la fecha del sistema.
Control Nº 11
Proporcione pruebas de que:
Existen entornos independientes para que:
Los entornos de desarrollo y prueba/ensayo aplican la separación de las tareas del entorno de producción.
La separación de tareas se aplica a través de controles de acceso.
Los datos de producción confidenciales no se usan dentro de los entornos de desarrollo o prueba/ensayo.
Intención: entornos independientes
La mayoría de los entornos de desarrollo y pruebas de las organizaciones no están configurados con el mismo vigor que los entornos de producción y, por tanto, son menos seguros. Además, las pruebas no deben realizarse dentro del entorno de producción, ya que esto puede introducir problemas de seguridad o puede ser perjudicial para la entrega de servicios para los clientes. Al mantener entornos independientes que aplican una separación de tareas, las organizaciones pueden asegurarse de que los cambios se aplican a los entornos correctos, lo que reduce el riesgo de errores mediante la implementación de cambios en entornos de producción cuando se ha diseñado para el entorno de desarrollo y pruebas.
Los controles de acceso deben configurarse de forma que el personal responsable del desarrollo y las pruebas no tenga acceso innecesario al entorno de producción y viceversa. Esto minimiza la posibilidad de que se produzcan cambios no autorizados o exposición de datos.
El uso de datos de producción en entornos de desarrollo y pruebas puede aumentar el riesgo de un riesgo y exponer a la organización a infracciones de datos o acceso no autorizado. La intención requiere que los datos utilizados para el desarrollo o las pruebas se desintegre, anonimicen o generen específicamente para ese propósito.
Directrices: entornos independientes
Se pueden proporcionar capturas de pantalla que muestran los diferentes entornos que se usan para entornos de desarrollo y pruebas y entornos de producción. Normalmente, tendría diferentes personas o equipos con acceso a cada entorno, o cuando esto no es posible, los entornos usarían diferentes servicios de autorización para asegurarse de que los usuarios no pueden iniciar sesión erróneamente en el entorno incorrecto para aplicar los cambios.
Evidencia de ejemplo: entornos independientes
En las capturas de pantalla siguientes se muestra que los entornos para desarrollo y pruebas están separados de producción; esto se logra a través de grupos de recursos en Azure, que es una manera de agrupar recursos lógicos en un contenedor. Otras formas de lograr la separación podrían ser diferentes suscripciones de Azure, redes y subredes, etc.
En la captura de pantalla siguiente se muestra el entorno de desarrollo y los recursos de este grupo de recursos.
En la captura de pantalla siguiente se muestra el entorno de producción y los recursos de este grupo de recursos.
Evidencia de ejemplo:
En las capturas de pantalla siguientes se muestra que los entornos de desarrollo y pruebas son independientes del entorno de producción. La separación adecuada de entornos se logra a través de diferentes usuarios o grupos con permisos diferentes asociados a cada entorno.
En la captura de pantalla siguiente se muestra el entorno de desarrollo y los usuarios con acceso a este grupo de recursos.
En la captura de pantalla siguiente se muestra el entorno de producción y los usuarios (distintos del entorno de desarrollo) que tienen acceso a este grupo de recursos.
Directrices:
La evidencia se puede proporcionar mediante el uso compartido de capturas de pantalla de la salida de la misma consulta SQL en una base de datos de producción (redacta cualquier información confidencial) y la base de datos de desarrollo y pruebas. La salida de los mismos comandos debe generar diferentes conjuntos de datos. Donde se almacenan los archivos, la visualización del contenido de las carpetas dentro de ambos entornos también debe mostrar diferentes conjuntos de datos.
Pruebas de ejemplo
En la captura de pantalla se muestran los tres registros principales (para el envío de pruebas, proporcione los 20 primeros) de la base de datos de producción.
En la captura de pantalla siguiente se muestra la misma consulta de la base de datos de desarrollo, en la que se muestran registros diferentes.
Nota: En este ejemplo no se usó una captura de pantalla completa, 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.
Protección del desarrollo o la implementación de software
Las organizaciones implicadas en actividades de desarrollo de software a menudo se enfrentan a prioridades de la competencia entre la seguridad y las presiones de TTM (tiempo de comercialización), pero la implementación de actividades relacionadas con la seguridad a lo largo del ciclo de vida de desarrollo de software (SDLC) no solo puede ahorrar dinero, sino que también puede ahorrar tiempo. Cuando la seguridad se deja como un concepto posterior, los problemas normalmente solo se identifican durante la fase de prueba de (DSLC), que a menudo puede ser más lento y costoso de corregir. La intención de esta sección de seguridad es garantizar que se siguen prácticas seguras de desarrollo de software para reducir el riesgo de que se introduzcan errores de codificación en el software que se desarrolla. Además, en esta sección se busca incluir algunos controles para ayudar a la implementación segura de software.
Control Nº 12
Proporcione pruebas que demuestren que existe documentación y se mantiene que:
es compatible con el desarrollo de software seguro e incluye estándares del sector o procedimientos recomendados para la codificación segura, como OWASP Top 10 o SANS Top 25 CWE.
los desarrolladores se someten a la codificación segura pertinente y al entrenamiento de desarrollo de software seguro anualmente.
Intención: desarrollo seguro
Las organizaciones deben hacer todo lo posible para garantizar que el software se desarrolle de forma segura y libre de vulnerabilidades. En un mejor esfuerzo por lograr esto, se debe establecer un ciclo de vida de desarrollo de software seguro (SDLC) sólido y procedimientos recomendados de codificación seguros para promover técnicas de codificación seguras y un desarrollo seguro a lo largo de todo el proceso de desarrollo de software. La intención es reducir el número y la gravedad de las vulnerabilidades en el software.
Existen procedimientos recomendados y técnicas de codificación para todos los lenguajes de programación a fin de garantizar que el código se desarrolle de forma segura. Hay cursos de entrenamiento externos diseñados para enseñar a los desarrolladores los diferentes tipos de clases de vulnerabilidades de software y las técnicas de codificación que se pueden usar para dejar de introducir estas vulnerabilidades en el software. La intención de este control es también enseñar estas técnicas a todos los desarrolladores y asegurarse de que estas técnicas no se olvidan, o las técnicas más recientes se aprenden realizando esto anualmente.
Directrices: desarrollo seguro
Proporcione la documentación documentada de SDLC o soporte técnico que demuestre que se está usando un ciclo de vida de desarrollo seguro y que se proporcionan instrucciones para que todos los desarrolladores promuevan procedimientos recomendados de codificación seguros. Eche un vistazo a OWASP en SDLC y al modelo de madurez de OWASP Software Assurance (SAMM).
Evidencia de ejemplo: desarrollo seguro
A continuación se muestra un ejemplo del documento De desarrollo de software seguro. A continuación se muestra un extracto del procedimiento de desarrollo de software seguro de Contoso, que muestra prácticas de desarrollo y codificación seguras.
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 cualquier dirección URL, el usuario que ha iniciado sesión y la hora y la fecha del sistema.
Directrices: entrenamiento de desarrollo seguro
Proporcione pruebas mediante certificados si el entrenamiento lo lleva a cabo una empresa de entrenamiento externa, o proporcionando capturas de pantalla de los diarios de entrenamiento u otros artefactos que muestran que los desarrolladores han asistido al entrenamiento. Si esta formación se lleva a cabo a través de recursos internos, proporcione también pruebas del material de formación.
Evidencia de ejemplo: entrenamiento de desarrollo seguro
La siguiente captura de pantalla es un correo electrónico que solicita al personal del equipo de DevOps que se inscriba en el entrenamiento anual de los diez primeros miembros de OWASP.
En la siguiente captura de pantalla se muestra que se ha solicitado el entrenamiento con justificación y aprobación empresariales. A continuación, se muestran capturas de pantalla tomadas del entrenamiento y un registro de finalización que muestra que la persona ha terminado el entrenamiento anual.
Nota: En este ejemplo no se usó una captura de pantalla completa, 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º 13
Proporcione pruebas de que los repositorios de código están protegidos para que:
todos los cambios de código se someten a un proceso de revisión y aprobación por parte de un segundo revisor antes de combinarse con la rama principal.
los controles de acceso adecuados están en su lugar.
todo el acceso se aplica a través de la autenticación multifactor (MFA).
todas las versiones realizadas en los entornos de producción se revisan y aprueban antes de su implementación.
Intención: revisión de código
La intención con este subpunto es realizar una revisión de código por parte de otro desarrollador para ayudar a identificar los errores de codificación que podrían introducir una vulnerabilidad en el software. Se debe establecer la autorización para asegurarse de que se llevan a cabo revisiones de código, se realizan pruebas, etc. antes de la implementación. El paso de autorización valida que se han seguido los procesos correctos que sustentan el SDLC definido en el control 12.
El objetivo es asegurarse de que todos los cambios de código se sometan a un riguroso proceso de revisión y aprobación por parte de un segundo revisor antes de combinarlos en la rama principal. Este proceso de aprobación dual sirve como medida de control de calidad, con el objetivo de detectar errores de codificación, vulnerabilidades de seguridad u otros problemas que podrían poner en peligro la integridad de la aplicación.
Directrices: revisión de código
Proporcione pruebas de que el código se somete a una revisión del mismo nivel y debe estar autorizado antes de que se pueda aplicar al entorno de producción. Esta evidencia puede ser a través de una exportación de vales de cambio, demostrando que se han realizado revisiones de código y los cambios autorizados, o podría ser a través de software de revisión de código como Crucible
Evidencia de ejemplo: revisión de código
A continuación se muestra un vale que muestra los cambios de código sometidos a un proceso de revisión y autorización por parte de alguien que no sea el desarrollador original. Muestra que el asignado ha solicitado una revisión de código y que se asignará a otra persona para la revisión de código.
En la imagen siguiente se muestra que la revisión de código se asignó a alguien distinto del desarrollador original, como se muestra en la sección resaltada en el lado derecho de la imagen. En el lado izquierdo, el revisor de código ha revisado el código y se le ha dado el estado "REVISIÓN DE CÓDIGO PASADO". El vale ahora debe obtener la aprobación de un administrador antes de que los cambios se puedan colocar en sistemas de producción en vivo.
En la imagen siguiente se muestra que el código revisado se ha aprobado para implementarse en los sistemas de producción en directo. Una vez realizados los cambios de código, el trabajo final se cierra. Tenga en cuenta que a lo largo del proceso hay tres personas implicadas, el desarrollador original del código, el revisor de código y un administrador para dar aprobación y cerrar la sesión. Para cumplir los criterios de este control, sería una expectativa que sus vales sigan este proceso.
Nota: En este ejemplo no se usó una captura de pantalla completa, 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: revisión de código
Además de la parte administrativa del proceso mostrada anteriormente, con repositorios de código modernos y plataformas se pueden implementar controles adicionales, como la revisión de aplicación de directivas de rama, para garantizar que las combinaciones no se puedan producir hasta que se complete dicha revisión. En el ejemplo siguiente se muestra que esto se logra en DevOps.
En la captura de pantalla siguiente se muestra que se asignan revisores predeterminados y se requiere revisión automáticamente.
Evidencia de ejemplo: revisión de código
La revisión de la aplicación de directivas de rama también se puede lograr en Bitbucket.
En la siguiente captura de pantalla se establece un revisor predeterminado. Esto garantiza que las combinaciones requerirán una revisión del individuo asignado antes de que el cambio se propague a la rama principal.
En las dos capturas de pantalla siguientes, se muestra un ejemplo de los valores de configuración que se aplican. Además de una solicitud de incorporación de cambios completada, que inició el usuario Silvester y requirió la aprobación del revisor predeterminado Andrew antes de combinarse con la rama principal.
Tenga en cuenta que cuando se proporcionen pruebas, la expectativa será que se demuestre el proceso de un extremo a otro. Nota: Se deben proporcionar capturas de pantalla que muestren los valores de configuración si hay una directiva de rama (o algún otro método o control mediante programación) y los vales o registros de aprobación que se conceden.
Intención: acceso restringido
A partir del control anterior, se deben implementar controles de acceso para limitar el acceso solo a usuarios individuales que trabajan en proyectos específicos. Al limitar el acceso, puede limitar el riesgo de que se realicen cambios no autorizados y, por tanto, introducir cambios de código no seguros. Se debe adoptar un enfoque con privilegios mínimos para proteger el repositorio de código.
Directrices: acceso restringido
Proporcione pruebas mediante capturas de pantalla del repositorio de código que indiquen que el acceso está restringido a las personas necesarias, incluidos los distintos privilegios.
Evidencia de ejemplo: acceso restringido
En las capturas de pantalla siguientes se muestran los controles de acceso que se han implementado en Azure DevOps. Se muestra que el "equipo de CloudDemo" tiene dos miembros y cada miembro tiene permisos diferentes.
Nota: En las capturas de pantalla siguientes se muestra un ejemplo del tipo de evidencia y formato que se espera que cumpla con este control. Esto no es en modo alguno extenso y los casos reales pueden diferir en la forma en que se implementan los controles de acceso.
Si los permisos se establecen en el nivel de grupo, se deben proporcionar pruebas de cada grupo y de los usuarios de ese grupo, como se muestra en el segundo ejemplo de Bitbucket.
En la captura de pantalla siguiente se muestran los miembros del "equipo de CloudDemo".
La imagen anterior muestra que Andrew Smith tiene privilegios significativamente más altos como propietario del proyecto que Silvester a continuación.
Pruebas de ejemplo
En la captura de pantalla siguiente, los controles de acceso implementados en Bitbucket se logran a través de permisos establecidos en el nivel de grupo. En el nivel de acceso del repositorio hay un grupo "Administrador" con un usuario y un grupo "Desarrollador" con otro usuario.
En las capturas de pantalla siguientes se muestra que cada uno de los usuarios pertenece a un grupo diferente y tiene un nivel de permisos diferente. Andrew Smith es el Administrador, y Silvester es parte del grupo Desarrollador, que solo le concede privilegios de desarrollador.
Intención: MFA
Si un actor de amenazas puede acceder a la base de código de un software y modificarla, podría introducir vulnerabilidades, puertas traseras o código malintencionado en la base de código y, por tanto, en la aplicación. Ya ha habido varias instancias de esto, siendo probablemente el más publicitado el ataque SolarWinds de 2020, donde los atacantes insertaron código malintencionado en un archivo que más adelante se incluyó en las actualizaciones de software de Orion de SolarWinds. Más de 18 000 clientes de SolarWinds instalaron las actualizaciones malintencionadas, con la propagación de malware sin detectar.
La intención de este subpunto es comprobar que todo el acceso a los repositorios de código se aplica a través de la autenticación multifactor (MFA).
Directrices: MFA
Proporcione pruebas mediante capturas de pantalla del repositorio de código que indican que todos los usuarios tienen MFA habilitado.
Prueba de ejemplo: MFA
Si los repositorios de código se almacenan y mantienen en Azure DevOps, en función de cómo se haya configurado MFA en el nivel de inquilino, se pueden proporcionar pruebas desde AAD, por ejemplo, "MFA por usuario". En la captura de pantalla siguiente se muestra que mfa se aplica a todos los usuarios de AAD y esto también se aplicará a Azure DevOps.
Prueba de ejemplo: MFA
Si la organización usa una plataforma como GitHub, puede demostrar que 2FA está habilitado compartiendo la evidencia de la cuenta "Organización", como se muestra en las capturas de pantalla siguientes.
Para ver si se aplica 2FA a todos los miembros de la organización en GitHub, puede navegar a la pestaña de configuración de la organización, como en la captura de pantalla siguiente.
Al navegar a la pestaña "Personas" en GitHub, se puede establecer que "2FA" está habilitado para todos los usuarios de la organización, como se muestra en la siguiente captura de pantalla.
Intención: revisiones
La intención con este control es realizar una revisión de la versión en un entorno de desarrollo por parte de otro desarrollador para ayudar a identificar los errores de codificación, así como configuraciones incorrectas que podrían introducir una vulnerabilidad. Se debe establecer la autorización para garantizar que se realicen revisiones de versiones, se realicen pruebas, etc. antes de la implementación en producción. La autorización. paso puede validar que se han seguido los procesos correctos que sustentan los principios sdlc.
Instrucciones
Proporcione pruebas de que todas las versiones del entorno de prueba o desarrollo en el entorno de producción están siendo revisadas por una persona o desarrollador diferente a la del iniciador. Si esto se logra a través de una canalización de integración continua o implementación continua, la evidencia proporcionada debe mostrar (igual que con las revisiones de código ) que se aplican las revisiones.
Pruebas de ejemplo
En la siguiente captura de pantalla, podemos ver que una canalización de CI/CD está en uso en Azure DevOps, la canalización contiene dos fases: Desarrollo y Producción. Se ha desencadenado una versión y se ha implementado correctamente en el entorno de desarrollo, pero aún no se ha propagado a la segunda fase (Producción) y está pendiente de aprobación de Andrew Smith.
La expectativa es que, una vez implementada en el desarrollo, el equipo pertinente realice pruebas de seguridad y solo cuando la persona asignada con la autoridad adecuada para revisar la implementación haya realizado una revisión secundaria y esté satisfecho de que se cumplan todas las condiciones, concederá la aprobación que permitirá que la versión se realice en producción.
La alerta de correo electrónico que normalmente recibiría el revisor asignado informando de que se desencadenó una condición previa a la implementación y que una revisión y aprobación están pendientes.
Mediante la notificación por correo electrónico, el revisor puede navegar a la canalización de versión en DevOps y conceder aprobación. Podemos ver a continuación que se agregan comentarios que justifican la aprobación.
En la segunda captura de pantalla se muestra que se concedió la aprobación y que la versión en producción se realizó correctamente.
Las dos capturas de pantalla siguientes muestran un ejemplo de la evidencia que se esperaría.
La evidencia muestra versiones históricas y que se aplican condiciones previas a la implementación, y se requiere una revisión y aprobación antes de que se pueda realizar la implementación en el entorno de producción.
Captura de pantalla siguiente que muestra el historial de versiones, incluida la versión reciente que podemos ver, se implementó correctamente tanto en desarrollo como en producción.
Nota: En los ejemplos anteriores no se usó una captura de pantalla completa, 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.
Administración de cuentas
Las prácticas de administración de cuentas seguras son importantes, ya que las cuentas de usuario constituyen la base para permitir el acceso a los sistemas de información, los entornos del sistema y los datos. Las cuentas de usuario deben protegerse correctamente como un riesgo de las credenciales del usuario puede proporcionar no solo un punto de apoyo en el entorno y el acceso a datos confidenciales, sino que también puede proporcionar control administrativo sobre todo el entorno o los sistemas clave si las credenciales del usuario tienen privilegios administrativos.
Control Nº 14
Proporcione pruebas de que:
Las credenciales predeterminadas se deshabilitan, quitan o cambian en los componentes del sistema muestreados.
Se ha implementado un proceso para proteger (proteger) las cuentas de servicio y que se ha seguido este proceso.
Intención: credenciales predeterminadas
Aunque esto es cada vez menos popular, todavía hay instancias en las que los actores de amenazas pueden aprovechar las credenciales de usuario predeterminadas y bien documentadas para poner en peligro los componentes del sistema de producción. Un ejemplo popular de esto es con Dell iDRAC (controlador de acceso remoto integrado de Dell). Este sistema se puede usar para administrar de forma remota un servidor Dell, que podría ser aprovechado por un actor de amenazas para obtener el control sobre el sistema operativo del servidor. La credencial predeterminada de root::calvin está documentada y, a menudo, los actores de amenazas pueden aprovecharla para obtener acceso a los sistemas utilizados por las organizaciones. La intención de este control es asegurarse de que las credenciales predeterminadas estén deshabilitadas o eliminadas para mejorar la seguridad.
Directrices: credenciales predeterminadas
Hay varias maneras en las que se pueden recopilar pruebas para respaldar este control. Las capturas de pantalla de los usuarios configurados en todos los componentes del sistema pueden ayudar, es decir, a las capturas de pantalla de las cuentas predeterminadas de Windows a través del símbolo del sistema (CMD) y para los archivos /etc/shadow y /etc/passwd de Linux, que le ayudarán a demostrar si las cuentas se han deshabilitado.
Evidencia de ejemplo: credenciales predeterminadas
En la captura de pantalla siguiente se muestra el archivo /etc/shadow para demostrar que las cuentas predeterminadas tienen una contraseña bloqueada y que las nuevas cuentas creadas o activas tienen una contraseña utilizable.
Tenga en cuenta que el archivo /etc/shadow sería necesario para demostrar que las cuentas están realmente deshabilitadas observando que el hash de contraseña comienza con un carácter no válido como '!' que indica que la contraseña no se puede usar. En las capturas de pantalla siguientes, la "L" significa bloquear la contraseña de la cuenta con nombre. Esta opción deshabilita una contraseña cambiandola a un valor que no coincide con ningún valor cifrado posible (agrega un valor al principio de la contraseña). "P" significa que es una contraseña utilizable.
En la segunda captura de pantalla se muestra que en el servidor windows, todas las cuentas predeterminadas se han deshabilitado. Mediante el comando "net user" en un terminal (CMD), puede enumerar los detalles de cada una de las cuentas existentes, observando que todas estas cuentas no están activas.
Mediante el comando net user en CMD, puede mostrar todas las cuentas y observar que todas las cuentas predeterminadas no están activas.
Intención: credenciales predeterminadas
A menudo, los actores de amenazas se dirigirán a las cuentas de servicio porque a menudo se configuran con privilegios elevados. Es posible que estas cuentas no sigan las directivas de contraseña estándar porque la expiración de contraseñas de cuenta de servicio a menudo interrumpe la funcionalidad. Por lo tanto, se pueden configurar con contraseñas o contraseñas débiles que se reutilizan dentro de la organización. Otro posible problema, especialmente en un entorno de Windows, puede ser que el sistema operativo almacene en caché el hash de contraseña. Esto puede ser un gran problema si:
la cuenta de servicio está configurada dentro de un servicio de directorio, ya que esta cuenta puede usarse para acceder a varios sistemas con el nivel de privilegios configurado, o
la cuenta de servicio es local, lo más probable es que se use la misma cuenta o contraseña en varios sistemas dentro del entorno.
Los problemas anteriores pueden dar lugar a que un actor de amenazas obtenga acceso a más sistemas dentro del entorno y puede conducir a una mayor elevación de privilegios o movimiento lateral. Por lo tanto, la intención es asegurarse de que las cuentas de servicio estén protegidas y protegidas correctamente para ayudar a protegerlas frente a la toma de control por parte de un actor de amenazas o limitando el riesgo en caso de que una de estas cuentas de servicio se vea comprometida. El control requiere que se establezca un proceso formal para la protección de estas cuentas, que puede incluir la restricción de permisos, el uso de contraseñas complejas y la rotación regular de credenciales.
Instrucciones
Hay muchas guías en Internet para ayudar a proteger las cuentas de servicio. La evidencia puede estar en forma de capturas de pantalla que muestran cómo la organización ha implementado una protección segura de la cuenta. Algunos ejemplos (la expectativa es que se usarían varias técnicas) incluyen:
Restringir las cuentas a un conjunto de equipos dentro de Active Directory,
Establecer la cuenta para que no se permita el inicio de sesión interactivo,
Establecer una contraseña extremadamente compleja,
Para Active Directory, habilite la marca "La cuenta es confidencial y no se puede delegar".
Pruebas de ejemplo
Hay varias maneras de proteger una cuenta de servicio que dependerá de cada entorno individual. Estos son algunos de los mecanismos que se pueden emplear:
En la captura de pantalla siguiente se muestra la opción "La cuenta es confidencial y la conexión se delegada" está seleccionada en la cuenta de servicio "_Prod cuenta de servicio de SQL".
En esta segunda captura de pantalla se muestra que la cuenta de servicio "_Prod cuenta de servicio de SQL" está bloqueada en SQL Server y solo puede iniciar sesión en ese servidor.
En esta captura de pantalla siguiente se muestra que la cuenta de servicio "_Prod cuenta de servicio de SQL" solo puede iniciar sesión como servicio.
Nota: En los ejemplos anteriores no se usó una captura de pantalla completa, 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º 15
Proporcione pruebas de que:
Las cuentas de usuario únicas se emiten a todos los usuarios.
Los principios de privilegios mínimos de usuario se siguen dentro del entorno.
Se ha implementado una directiva de contraseña o frase de contraseña segura u otras mitigaciones adecuadas.
Se ha implementado un proceso que se sigue al menos cada tres meses para deshabilitar o eliminar cuentas que no se usan en un plazo de 3 meses.
Intención: cuentas de servicio seguras
La intención de este control es la responsabilidad. Al emitir usuarios con sus propias cuentas de usuario únicas, los usuarios serán responsables de sus acciones, ya que se puede realizar un seguimiento de la actividad del usuario a un usuario individual.
Directrices: cuentas de servicio seguras
La evidencia sería a través de capturas de pantalla que muestran las cuentas de usuario configuradas en los componentes del sistema en el ámbito que pueden incluir servidores, repositorios de código, plataformas de administración en la nube, Active Directory, Firewalls, etc.
Evidencia de ejemplo: cuentas de servicio seguras
En la captura de pantalla siguiente se muestran las cuentas de usuario configuradas para el entorno de Azure en el ámbito y que todas las cuentas son únicas.
Intención: privilegios
Solo se deben proporcionar a los usuarios los privilegios necesarios para cumplir su función de trabajo. Esto es para limitar el riesgo de que un usuario acceda a los datos de forma intencionada o involuntaria, no debería o llevar a cabo una
acto malintencionado. Siguiendo este principio, también reduce la superficie de ataque potencial (es decir, las cuentas con privilegios) que puede ser dirigida por un actor de amenazas malintencionado.
Directrices: privilegios
La mayoría de las organizaciones usarán grupos para asignar privilegios en función de los equipos de la organización. La evidencia podría ser capturas de pantalla que muestran los distintos grupos con privilegios y solo las cuentas de usuario de los equipos que requieren estos privilegios. Normalmente, se realizaría una copia de seguridad con directivas o procesos auxiliares que definen cada grupo definido con los privilegios necesarios y la justificación empresarial, y una jerarquía de miembros del equipo para validar que la pertenencia a grupos está configurada correctamente.
Por ejemplo: en Azure, el grupo Propietarios debe ser muy limitado, por lo que debe documentarse y tener un número limitado de personas asignadas a ese grupo. Otro ejemplo podría ser un número limitado de personal con la capacidad de realizar cambios en el código; es posible que se configure un grupo con este privilegio con los miembros del personal que se considere que necesitan este permiso configurado. Esto debe documentarse para que el analista de certificación pueda hacer referencia cruzada al documento con los grupos configurados, etc.
Evidencia de ejemplo: privilegios
En las capturas de pantalla siguientes se muestra el principio de privilegios mínimos en un entorno de Azure.
En la captura de pantalla siguiente se resalta el uso de varios grupos en Azure Active Directory (AAD)/Microsoft Entra. Observe que hay tres grupos de seguridad, desarrolladores, ingenieros jefes y operaciones de seguridad.
Al navegar al grupo "Desarrolladores", en el nivel de grupo los únicos roles asignados son "Desarrollador de aplicaciones" y "Lectores de directorio".
En la captura de pantalla siguiente se muestran los miembros del grupo "Developers".
Por último, en la captura de pantalla siguiente se muestra el propietario del grupo.
A diferencia del grupo "Desarrolladores", "Operaciones de seguridad" tiene diferentes roles asignados, es decir, "Operador de seguridad" que está en consonancia con el requisito de trabajo.
En la captura de pantalla siguiente se muestra que hay miembros diferentes que forman parte del grupo "Operaciones de seguridad".
Por último, el grupo tiene un propietario diferente.
Los administradores globales son un rol con privilegios elevados y las organizaciones deben decidir el nivel de riesgo que quieren aceptar al proporcionar este tipo de acceso. En el ejemplo proporcionado solo hay dos usuarios que tienen este rol. Esto es para garantizar que la superficie expuesta a ataques y el impacto se reduzcan.
Intención: directiva de contraseña
Las credenciales de usuario suelen ser el objetivo de ataque por parte de los actores de amenazas que intentan obtener acceso al entorno de una organización. La intención de una directiva de contraseña segura es intentar forzar a los usuarios a elegir contraseñas seguras para mitigar las posibilidades de que los actores de amenazas puedan forzarlas brutamente. La intención de agregar "u otras mitigaciones adecuadas" es reconocer que las organizaciones pueden implementar otras medidas de seguridad para ayudar a proteger las credenciales de usuario en función de los desarrollos del sector, como la publicación especial 800-63B de NIST.
Directrices: directiva de contraseñas
La evidencia para demostrar una directiva de contraseña segura puede estar en forma de una captura de pantalla de un objeto de directiva de grupo de organizaciones o una directiva de seguridad local "Directivas de cuenta → directiva de contraseña" y "Directivas de cuenta → directiva de bloqueo de cuenta". La evidencia depende de las tecnologías que se usan, es decir, para Linux podría ser el archivo de configuración /etc/pam.d/common-password, para Bitbucket la sección "Directivas de autenticación" en el Portal de administración [Administrar la directiva de contraseña | Soporte técnico de Atlassian, etc.
Evidencia de ejemplo: directiva de contraseña
La evidencia siguiente muestra la directiva de contraseña configurada dentro de la "Directiva de seguridad local" del componente del sistema en ámbito "CONTOSO-SRV1".
En la captura de pantalla siguiente se muestra la configuración de bloqueo de cuenta para un firewall de WatchGuard.
A continuación se muestra un ejemplo de una longitud de frase de contraseña mínima para el firewall de WatchGuard.
Nota: En los ejemplos anteriores no se usó una captura de pantalla completa, 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: cuentas inactivas
Las cuentas inactivas a veces se pueden poner en peligro porque están destinadas a ataques por fuerza bruta que no se pueden marcar como que el usuario no intentará iniciar sesión en las cuentas, o bien por una vulneración de la base de datos de contraseñas en la que la contraseña de un usuario se ha reutilizado y está disponible en un volcado de nombre de usuario o contraseña en Internet. Las cuentas sin usar deben deshabilitarse o quitarse para reducir la superficie expuesta a ataques que un actor de amenazas tiene que llevar a cabo actividades de riesgo de cuenta. Estas cuentas pueden deberse a un proceso de permisos que no se lleva a cabo correctamente, a un miembro del personal que se encuentra en una enfermedad a largo plazo o a un miembro del personal que está de baja por maternidad o paternidad. Al implementar un proceso trimestral para identificar estas cuentas, las organizaciones pueden minimizar la superficie expuesta a ataques.
Este control exige que se realice un proceso y se siga al menos cada tres meses para deshabilitar o eliminar cuentas que no se han usado en los últimos tres meses con el objetivo de reducir el riesgo, garantizando revisiones periódicas de cuentas y desactivación oportuna de las cuentas no utilizadas.
Directrices: cuentas inactivas
La evidencia debe ser doble:
En primer lugar, una captura de pantalla o exportación de archivos que muestra el "último inicio de sesión" de todas las cuentas de usuario dentro del entorno de ámbito. Puede tratarse de cuentas locales, así como cuentas dentro de un servicio de directorio centralizado, como AAD (Azure Active Directory). Esto demostrará que no hay ninguna cuenta de más de 3 meses habilitada.
En segundo lugar, pruebas del proceso de revisión trimestral que pueden ser pruebas documentales de la tarea que se completa dentro de ADO (Azure DevOps) o vales JIRA, o a través de registros en papel que se deben firmar.
Evidencia de ejemplo: cuentas inactivas
En la siguiente captura de pantalla se muestra que se ha utilizado una plataforma en la nube para realizar revisiones de acceso. Esto se ha logrado mediante la característica de gobernanza de identidades en Azure.
En la siguiente captura de pantalla se muestra el historial de revisión, el período de revisión y el estado.
El panel y las métricas de la revisión proporcionan detalles adicionales, como el ámbito que son todos los usuarios de la organización y el resultado de la revisión, así como la frecuencia que es trimestral.
Al evaluar los resultados de la revisión, la imagen indica que se ha proporcionado una acción recomendada, que se basa en condiciones preconfiguradas. Además, requiere que una persona asignada aplique manualmente las decisiones de la revisión.
Puede observar en lo siguiente que para cada empleado hay una recomendación y una justificación proporcionadas. Como se mencionó, una persona asignada requiere la decisión de aceptar la recomendación o omitirla antes de aplicar la revisión. Si la decisión final está en contra de la recomendación, entonces la expectativa será que se proporcionen pruebas para explicar por qué.
Control Nº 16
Valide que la autenticación multifactor (MFA) está configurada para todas las conexiones de acceso remoto y todas las interfaces administrativas que no son de consola, incluido el acceso a los repositorios de código e interfaces de administración en la nube.
Significado de estos términos
Acceso remoto: se refiere a las tecnologías que se usan para acceder al entorno auxiliar. Por ejemplo, VPN IPSec de acceso remoto, VPN SSL o Jumpbox/Bastian Host.
Interfaces administrativas que no son de consola: se refiere a las conexiones administrativas de red a los componentes del sistema. Esto podría ser a través de Escritorio remoto, SSH o una interfaz web.
Repositorios de código: la base de código de la aplicación debe protegerse contra modificaciones malintencionadas que podrían introducir malware en la aplicación. MFA debe configurarse en los repositorios de código.
Interfaces de administración en la nube: donde algunos o todos los entornos se hospedan dentro del proveedor de servicios en la nube (CSP). La interfaz administrativa para la administración en la nube se incluye aquí.
Intención: MFA
La intención de este control es proporcionar mitigaciones contra ataques por fuerza bruta en cuentas con privilegios con acceso seguro al entorno mediante la implementación de la autenticación multifactor (MFA). Incluso si se pone en peligro una contraseña, el mecanismo de MFA debe protegerse para garantizar que todos los miembros del personal autorizado y de confianza solo llevan a cabo todas las acciones administrativas y de acceso.
Para mejorar la seguridad, es importante agregar una capa adicional de seguridad para las conexiones de acceso remoto y las interfaces administrativas que no son de consola mediante MFA. Las conexiones de acceso remoto son especialmente vulnerables a la entrada no autorizada, y las interfaces administrativas controlan funciones con privilegios elevados, lo que hace que ambas áreas críticas requieran medidas de seguridad mejoradas. Además, los repositorios de código contienen trabajo de desarrollo confidencial y las interfaces de administración en la nube proporcionan un acceso amplio a los recursos en la nube de una organización, lo que los convierte en puntos críticos adicionales que deben protegerse con MFA.
Directrices: MFA
La evidencia debe mostrar que MFA está habilitado en todas las tecnologías que encajan en las categorías anteriores. Esto puede hacerse a través de una captura de pantalla que muestra que MFA está habilitado en el nivel del sistema. Por nivel de sistema, necesitamos pruebas de que está habilitada para todos los usuarios y no solo un ejemplo de una cuenta con MFA habilitado. Cuando la tecnología se respalda en una solución de MFA, necesitamos la evidencia para demostrar que está habilitada y en uso. Lo que significa esto es; donde la tecnología está configurada para la autenticación radius, que apunta a un proveedor de MFA, también debe demostrar que el servidor radius al que apunta, es una solución mfa y que las cuentas están configuradas para usarla.
Prueba de ejemplo: MFA
En las capturas de pantalla siguientes se muestra cómo se puede implementar una directiva condicional de MFA en AAD/Entra para aplicar el requisito de autenticación en dos fases en toda la organización. Podemos ver en lo siguiente que la directiva está "activada".
En la captura de pantalla siguiente se muestra que la directiva de MFA se va a aplicar a todos los usuarios de la organización y que está habilitada.
En la siguiente captura de pantalla se muestra que el acceso se concede al cumplir la condición de MFA. En el lado derecho de la captura de pantalla, podemos ver que el acceso solo se concederá a un usuario una vez que se implemente MFA.
Prueba de ejemplo: MFA
Se pueden implementar controles adicionales, como un requisito de registro de MFA, que garantiza que, tras el registro, los usuarios deberán configurar MFA antes de que se dé acceso a su nueva cuenta. Puede observar a continuación la configuración de una directiva de registro de MFA que se aplica a todos los usuarios.
En la continuación de la captura de pantalla anterior que muestra la directiva que se va a aplicar sin exclusiones, la siguiente captura de pantalla muestra que todos los usuarios están incluidos en la directiva.
Prueba de ejemplo: MFA
En la siguiente captura de pantalla se muestra que la página "MFA por usuario" muestra que mfa se aplica a todos los usuarios.
Prueba de ejemplo: MFA
En las capturas de pantalla siguientes se muestran los dominios de autenticación configurados en Pulse Secure, que se usan para el acceso remoto al entorno. La autenticación está respaldada por el servicio SaaS de Duo para la compatibilidad con MFA.
En esta captura de pantalla se muestra que está habilitado un servidor de autenticación adicional que apunta a "Duo-LDAP" para el dominio de autenticación "Duo - Default Route".
En esta captura de pantalla final se muestra la configuración del servidor de autenticación Duo-LDAP, que muestra que apunta al servicio SaaS duo para MFA.
Nota: En los ejemplos anteriores no se usó una captura de pantalla completa, 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.
Registro, revisión y alertas de eventos de seguridad
El registro de eventos de seguridad es una parte integral del programa de seguridad de una organización. El registro adecuado de eventos de seguridad junto con los procesos de alerta y revisión optimizados ayudan a las organizaciones a identificar infracciones o intentos de infracciones que la organización puede usar para mejorar las estrategias de seguridad defensiva y de seguridad. Además, el registro adecuado será fundamental para una capacidad de respuesta a incidentes de las organizaciones que puede alimentarse en otras actividades, como la capacidad de identificar con precisión qué datos y quién se han puesto en peligro, el período de peligro, proporcionar informes de análisis detallados a las agencias gubernamentales, etc.
La revisión de los registros de seguridad es una función importante para ayudar a las organizaciones a identificar eventos de seguridad que pueden indicar una infracción de seguridad o actividades de reconocimiento que pueden ser una indicación de algo por venir. Esto se puede realizar a través de un proceso manual diario o mediante una solución SIEM (Administración de eventos e información de seguridad) que ayuda a analizar los registros de auditoría, buscar correlaciones y anomalías que se pueden marcar para una inspección manual.
Los eventos de seguridad críticos deben investigarse inmediatamente para minimizar el impacto en los datos y el entorno operativo. Las alertas ayudan a resaltar inmediatamente posibles infracciones de seguridad para el personal para garantizar una respuesta oportuna para que la organización pueda contener el evento de seguridad lo antes posible. Al garantizar que las alertas funcionan de forma eficaz, las organizaciones pueden minimizar el impacto de una infracción de seguridad, lo que reduce la posibilidad de una infracción grave que podría dañar la marca de las organizaciones e imponer pérdidas financieras a través de multas y daños a la reputación.
Control Nº 17
Proporcione pruebas de que el registro de eventos de seguridad está configurado en el entorno dentro del ámbito para registrar eventos cuando corresponda, como:
Acceso de usuario o s a componentes del sistema y a la aplicación.
Todas las acciones realizadas por un usuario con privilegios elevados.
Intentos de acceso lógico no válidos.
Creación o modificación de cuentas con privilegios.
Manipulación del registro de eventos.
Deshabilitación de herramientas de seguridad; por ejemplo, el registro de eventos.
Registro antimalware; por ejemplo, actualizaciones, detección de malware, errores de examen.
Intención: registro de eventos
Para identificar las infracciones intentadas y reales, es importante que todos los sistemas que componen el entorno recopilen los registros de eventos de seguridad adecuados. La intención de este control es asegurarse de que se capturan los tipos correctos de eventos de seguridad que, a continuación, pueden pasar a procesos de revisión y alerta para ayudar a identificar y responder a estos eventos.
Este subpunto requiere que un ISV haya configurado el registro de eventos de seguridad para capturar todas las instancias de acceso de usuario a componentes y aplicaciones del sistema. Esto es fundamental para supervisar quién accede a los componentes del sistema y las aplicaciones dentro de la organización y es esencial para fines de seguridad y auditoría.
Este subpunto requiere que se registren todas las acciones realizadas por los usuarios con privilegios de alto nivel. Los usuarios con privilegios elevados pueden realizar cambios significativos que podrían afectar a la posición de seguridad de la organización. Por lo tanto, es fundamental mantener un registro de sus acciones.
Este subpunto requiere el registro de cualquier intento no válido de obtener acceso lógico a componentes o aplicaciones del sistema. Este registro es una manera principal de detectar intentos de acceso no autorizados y posibles amenazas de seguridad.
Este subpunto requiere registrar cualquier creación o modificación de cuentas con acceso con privilegios. Este tipo de registro es fundamental para realizar el seguimiento de los cambios en las cuentas que tienen un alto nivel de acceso al sistema y que podrían ser dirigidos por los atacantes.
Este subpunto requiere el registro de cualquier intento de alteración de los registros de eventos. La manipulación de registros puede ser una manera de ocultar actividades no autorizadas y, por lo tanto, es fundamental que dichas acciones se registren y actúen sobre ellos.
Este subpunto requiere el registro de cualquier acción que deshabilite las herramientas de seguridad, incluido el propio registro de eventos. Deshabilitar las herramientas de seguridad puede ser una marca roja que indica un ataque o una amenaza interna.
Este subpunto requiere el registro de actividades relacionadas con las herramientas antimalware, incluidas las actualizaciones, la detección de malware y los errores de examen. El correcto funcionamiento y la actualización de las herramientas antimalware son esenciales para la seguridad de una organización y los registros relacionados con estas actividades ayudan con la supervisión.
Directrices: registro de eventos
Se deben proporcionar pruebas mediante capturas de pantalla o opciones de configuración en todos los dispositivos muestreados y los componentes del sistema de relevancia para demostrar cómo se configura el registro para garantizar que se capturan estos tipos de eventos de seguridad.
Pruebas de ejemplo
En las capturas de pantalla siguientes se muestran las configuraciones de registros y métricas generadas por diferentes recursos en Azure, que luego se ingieren en el área de trabajo de Log Analytics centralizada.
Podemos ver en la primera captura de pantalla que la ubicación del almacenamiento de registros es "PaaS-web-app-log-analytics".
En Azure, la configuración de diagnóstico se puede habilitar en los recursos de Azure para acceder a registros de auditoría, seguridad y diagnóstico, como se muestra a continuación. Los registros de actividad, que están disponibles automáticamente, incluyen el origen del evento, la fecha, el usuario, la marca de tiempo, las direcciones de origen, las direcciones de destino y otros elementos útiles.
Tenga en cuenta: En los ejemplos siguientes se muestra un tipo de evidencia que se puede proporcionar para cumplir con este control. Esto depende de cómo la organización haya configurado el registro de eventos de seguridad en el entorno dentro del ámbito. Otros ejemplos pueden incluir Azure Sentinel, Datadog, etc.
Con la opción "Configuración de diagnóstico" para la aplicación web hospedada en Azure App Services, puede configurar qué registros se generan y dónde se envían para el almacenamiento y el análisis.
En la captura de pantalla siguiente, "Access Audit logs" y "IPSecurity Audit Logs" están configurados para generarse y capturarse en el área de trabajo de Log Analytics.
Otro ejemplo es para Azure Front Door, que está configurado para enviar registros generados a la misma área de trabajo de Análisis de registros centralizada.
Como antes de usar la opción "Configuración de diagnóstico", configure qué registros se generan y dónde se envían para el almacenamiento y el análisis. En la captura de pantalla siguiente se muestra que se han configurado "Registros de acceso" y "registros de WAF".
De forma similar, para Azure SQL Server, la "Configuración de diagnóstico" puede configurar qué registros se generan y dónde se envían para el almacenamiento y el análisis.
En la captura de pantalla siguiente se muestra que los registros de "auditoría" del servidor SQL Server se generan y envían al área de trabajo de Log Analytics.
Pruebas de ejemplo
En la captura de pantalla siguiente de AAD/Entra se muestra que se están generando registros de auditoría para administradores y roles con privilegios. La información incluye el estado, la actividad, el servicio, el destino y el iniciador.
En la captura de pantalla siguiente se muestran los registros de inicio de sesión. La información de registro incluye la dirección IP, el estado, la ubicación y la fecha.
Pruebas de ejemplo
El ejemplo siguiente se centra en los registros generados para instancias de proceso, como máquinas virtuales (VM). Se ha implementado una regla de recopilación de datos y se capturan los registros de eventos de Windows, incluidos los registros de auditoría de seguridad.
En la captura de pantalla siguiente se muestra otro ejemplo de configuración de un dispositivo muestreado denominado "Galaxy-Compliance". La configuración muestra las distintas opciones de auditoría habilitadas en la "Directiva de seguridad local".
En esta captura de pantalla siguiente se muestra un evento en el que un usuario ha borrado el registro de eventos del dispositivo muestreado "Galaxy-Compliance".
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.
Control Nº 18
Proporcione pruebas de que los datos de registro de eventos de seguridad de un mínimo de 30 días están disponibles inmediatamente, con 90 días de registros de eventos de seguridad que se conservan.
Intención: registro de eventos
A veces hay un intervalo de tiempo entre un evento de seguridad o peligro y una organización que lo identifica. La intención de este control es asegurarse de que la organización tiene acceso a datos de eventos históricos para ayudar con la respuesta a incidentes y cualquier trabajo de investigación forense que pueda ser necesario. Asegurarse de que la organización conserva un mínimo de 30 días de datos de registro de eventos de seguridad que están disponibles inmediatamente para su análisis a fin de facilitar la investigación rápida y la respuesta a incidentes de seguridad. Además, se conserva un total de 90 días de registros de eventos de seguridad para permitir un análisis detallado.
Directrices: registro de eventos
La evidencia suele ser mediante la visualización de los valores de configuración de la solución de registro centralizado, que muestra cuánto tiempo se conservan los datos. Los datos de registro de eventos de seguridad de 30 días deben estar disponibles inmediatamente dentro de la solución. Sin embargo, cuando se archivan los datos debe demostrar que hay disponible un valor de 90 días. Esto podría deberse a que se muestran carpetas de archivo con fechas de datos exportados.
Evidencia de ejemplo: registro de eventos
Siguiendo el ejemplo anterior de Control 17, donde un área de trabajo de Log Analytics centralizada está en uso para almacenar todos los registros generados por los recursos en la nube, puede observar a continuación que los registros se almacenan en tablas individuales para cada categoría de registro. Además, la retención interactiva para todas las tablas es de 90 días.
En la captura de pantalla siguiente se proporcionan pruebas adicionales que muestran los valores de configuración para el período de retención del área de trabajo de Log Analytics.
Pruebas de ejemplo
En las capturas de pantalla siguientes se muestra que los registros de 30 días están disponibles en AlienVault.
Nota: Dado que se trata de un documento público, se ha redactado el número de serie del firewall; sin embargo, los ISV deberán enviar esta información sin censuras, a menos que contenga información de identificación personal (PII) que se debe revelar a su analista.
En esta captura de pantalla siguiente se muestra que los registros están disponibles al mostrar un extracto de registro que retrocede cinco meses.
Nota: Dado que se trata de un documento público, las direcciones IP públicas se han redactado, sin embargo, los ISV tendrán que enviar esta información sin ninguna censura, a menos que contenga información de identificación personal (PII) que deben analizar primero con su analista.
Nota: 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.
Pruebas de ejemplo
En la siguiente captura de pantalla se muestra que los eventos de registro se mantienen durante 30 días disponibles en directo y 90 días en almacenamiento en frío en Azure.
Tenga en cuenta: La expectativa es que, además de cualquier configuración que muestre la retención configurada, se proporcione un ejemplo de registros del período de 90 días para validar que los registros se conservan durante 90 días.
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º 19
Proporcione pruebas que demuestren lo siguiente:
Los registros se revisan periódicamente y se investigan y abordan los posibles eventos o anomalías de seguridad identificados durante el proceso de revisión.
Intención: registro de eventos
La intención de este control es asegurarse de que se están realizando revisiones periódicas de registros. Esto es importante para identificar las anomalías que pueden no ser detectadas por los scripts o consultas de alertas que están configurados para proporcionar alertas de eventos de seguridad. Además, se investigan las anomalías que se identifican durante las revisiones de registro y se lleva a cabo la corrección o acción adecuada. Normalmente, esto implicará un proceso de evaluación de prioridades para identificar si las anomalías requieren acción y, a continuación, pueden necesitar invocar el proceso de respuesta a incidentes.
Directrices: registro de eventos
Las capturas de pantalla proporcionarán pruebas que demuestren que se están realizando revisiones de registros. Esto puede deberse a formularios que se completan cada día, o a través de un vale JIRA o DevOps con
comentarios pertinentes que se publican para mostrar que esto se lleva a cabo. Si se marcan anomalías, esto se puede documentar en este mismo vale para demostrar que las anomalías identificadas como parte de la revisión del registro se siguen y, a continuación, se detallan las actividades que se llevaron a cabo posteriormente. Esto puede pedir que se produzca un vale JIRA específico para realizar un seguimiento de todas las actividades que se llevan a cabo, o puede que simplemente se documente en el vale de revisión del registro. Si se requiere una acción de respuesta a incidentes, debe documentarse como parte del proceso de respuesta a incidentes y se deben proporcionar pruebas para demostrarlo.
Evidencia de ejemplo: registro de eventos
En esta primera captura de pantalla se identifica dónde se ha agregado un usuario al grupo "Administradores de dominio".
En esta captura de pantalla siguiente se identifica dónde se producen varios intentos de inicio de sesión con errores seguidos de un inicio de sesión correcto que puede resaltar un ataque por fuerza bruta correcto.
En esta captura de pantalla final se identifica dónde se ha producido un cambio de directiva de contraseña al establecer la directiva, por lo que las contraseñas de cuenta no expiran.
En esta captura de pantalla siguiente se muestra que se genera automáticamente un vale dentro de la herramienta ServiceNow del SOC, lo que desencadena la regla anterior.
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º 20
Proporcione pruebas que demuestren lo siguiente:
Las reglas de alerta se configuran para que las alertas se desencadenen para la investigación de los siguientes eventos de seguridad cuando corresponda:
Creación o modificación de cuentas con privilegios.
Operaciones o actividades con privilegios o alto riesgo.
Eventos de malware.
Manipulación del registro de eventos.
Eventos IDPS/WAF (si está configurado).
Intención: alertas
Estos son algunos tipos de eventos de seguridad que podrían resaltar que se ha producido un evento de seguridad que puede apuntar a una vulneración del entorno o a una vulneración de datos.
Este subpunto consiste en asegurarse de que las reglas de alerta están configuradas específicamente para desencadenar investigaciones tras la creación o modificación de cuentas con privilegios. En el caso de la creación o modificación de cuentas con privilegios, se deben generar registros y se deben desencadenar alertas cada vez que se cree una nueva cuenta con privilegios o se modifiquen los permisos de cuenta con privilegios existentes. Esto ayuda a realizar un seguimiento de las actividades no autorizadas o sospechosas.
Este subpunto tiene como objetivo establecer reglas de alerta para notificar al personal adecuado cuando se llevan a cabo actividades o operaciones con privilegios o de alto riesgo. En el caso de las actividades o operaciones con privilegios o de alto riesgo, se deben configurar alertas para notificar al personal adecuado cuando se inicien dichas actividades. Esto podría incluir cambios en las reglas de firewall, transferencias de datos o acceso a archivos confidenciales.
La intención de este subpunto es exigir la configuración de reglas de alerta desencadenadas por eventos relacionados con malware. Los eventos de malware no solo deben registrarse, sino que también deben desencadenar una alerta inmediata para su investigación. Estas alertas deben diseñarse para incluir detalles como el origen, la naturaleza del malware y los componentes del sistema afectados para acelerar el tiempo de respuesta.
Este subpunto está diseñado para asegurarse de que cualquier alteración de los registros de eventos desencadena una alerta inmediata para su investigación. Con respecto a la alteración del registro de eventos, el sistema debe configurarse para desencadenar alertas cuando se detecte acceso no autorizado a registros o modificaciones de registros. Esto garantiza la integridad de los registros de eventos, que son fundamentales para el análisis forense y las auditorías de cumplimiento.
Este subpunto tiene la intención de asegurarse de que, si se configuran sistemas de detección y prevención de intrusiones (IDPS) o firewalls de aplicaciones web (WAF), se establecen para desencadenar alertas para su investigación. Si se configuran sistemas de detección y prevención de intrusiones (IDPS) o firewalls de aplicaciones web (WAF), también deben establecerse para desencadenar alertas para actividades sospechosas, como errores de inicio de sesión repetidos, intentos de inyección de SQL o patrones que sugieran un ataque por denegación de servicio.
Directrices: alertas
Las pruebas deben proporcionarse mediante capturas de pantalla de la configuración de alertas y pruebas de las alertas que se reciben. Las capturas de pantalla de configuración deben mostrar la lógica que desencadena las alertas y cómo se envían las alertas. Las alertas se pueden enviar a través de SMS, correo electrónico, canales de Teams, canales de Slack, etc.
Evidencia de ejemplo: alertas
En la captura de pantalla siguiente se muestra un ejemplo de alertas que se configuran en Azure. Podemos observar en la primera captura de pantalla que se ha desencadenado una alerta cuando la máquina virtual se detuvo y desasignó. Tenga en cuenta que esto representa un ejemplo de alertas que se configuran en Azure y la expectativa es que se proporcionen pruebas para demostrar que se generan alertas para todos los eventos especificados en la descripción del control.
En la captura de pantalla siguiente se muestran las alertas configuradas para las acciones administrativas realizadas en el nivel de Azure App Service, así como en el nivel de grupo de recursos de Azure.
Pruebas de ejemplo
Contoso usa un centro de operaciones de seguridad (SOC) de terceros proporcionado por Contoso Security. En el ejemplo se muestra que las alertas dentro de AlienVault, utilizadas por el SOC, están configuradas para enviar una alerta a un miembro del equipo de SOC, Sally Gold en Contoso Security.
En esta captura de pantalla siguiente se muestra una alerta que recibe Sally.
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.
Administración de riesgos de seguridad de la información
Administración de riesgos de seguridad de la información es una actividad importante que todas las organizaciones deben llevar a cabo al menos anualmente. Las organizaciones deben comprender sus riesgos para mitigar eficazmente las amenazas. Sin una administración eficaz de riesgos, las organizaciones pueden implementar recursos de seguridad en áreas que perciben importantes, cuando otras amenazas pueden ser más probables. La administración eficaz de riesgos ayudará a las organizaciones a centrarse en los riesgos que representan la mayor amenaza para la empresa. Esto debe llevarse a cabo anualmente, ya que el panorama de seguridad está cambiando y, por lo tanto, las amenazas y los riesgos pueden cambiar con el tiempo. Por ejemplo, durante el reciente bloqueo de COVID-19 se produjo un gran aumento de ataques de suplantación de identidad (phishing) con el traslado al trabajo remoto.
Control Nº 21
Proporcione pruebas de que se documenta y establece una directiva o proceso de administración de riesgos de seguridad de la información formal ratificada.
Intención: administración de riesgos
Un sólido proceso de administración de riesgos de seguridad de la información es importante para ayudar a las organizaciones a administrar los riesgos de forma eficaz. Esto ayudará a las organizaciones a planear mitigaciones eficaces contra amenazas para el entorno. La intención de este control es confirmar que la organización tiene una directiva o proceso de administración de riesgos de seguridad de la información formalmente ratificada que está documentado de forma completa. La directiva debe describir cómo la organización identifica, evalúa y administra los riesgos de seguridad de la información. Debe incluir roles y responsabilidades, metodologías para la evaluación de riesgos, criterios para la aceptación de riesgos y procedimientos para la mitigación de riesgos.
Nota: La evaluación de riesgos debe centrarse en los riesgos de seguridad de la información, no solo en los riesgos empresariales generales.
Directrices: administración de riesgos
Se debe proporcionar el proceso de gestión de la evaluación de riesgos formalmente documentado.
Evidencia de ejemplo: administración de riesgos
La siguiente evidencia es una captura de pantalla de parte del proceso de evaluación de riesgos de Contoso.
Nota: 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 los ISV compartan la documentación real de procedimientos o directivas auxiliares y no simplemente proporcionen una captura de pantalla.
Control Nº 22
Proporcione pruebas que demuestren lo siguiente:
- Al menos anualmente se lleva a cabo una evaluación formal de los riesgos de seguridad de la información en toda la empresa.
O bien, para el análisis de riesgos de destino:
Se documenta y realiza un análisis de riesgo dirigido:
Como mínimo cada 12 meses para cada instancia en la que no se haya implementado un control tradicional o un procedimiento recomendado del sector.
Cuando una limitación tecnológica o de diseño crea un riesgo de introducir una vulnerabilidad en el entorno o pone a los usuarios y los datos en riesgo.
Bajo sospecha o confirmación de compromiso.
Intención: evaluación anual
Las amenazas de seguridad cambian constantemente en función de los cambios en el entorno, los cambios en los servicios ofrecidos, las influencias externas, la evolución del panorama de amenazas de seguridad, etc. Las organizaciones deben pasar por el proceso de evaluación de riesgos al menos anualmente. Se recomienda que este proceso también se lleve a cabo con cambios significativos, ya que las amenazas pueden cambiar.
La intención de este control es determinar que la organización lleva a cabo una evaluación formal de riesgos de seguridad de la información en toda la empresa al menos una vez al año y/o un análisis de riesgos dirigido durante los cambios del sistema o sobre incidentes, detección de vulnerabilidades, cambios en la infraestructura, etc. Esta evaluación debe abarcar todos los recursos, procesos y datos de la organización, con el objetivo de identificar y evaluar posibles vulnerabilidades y amenazas.
Para el análisis de riesgos de destino, este control hace hincapié en la necesidad de realizar análisis de riesgos en escenarios específicos; esto se centra en un ámbito más restringido, como un recurso, una amenaza, un sistema o un control. La intención de esto es garantizar que las organizaciones evalúen e identifiquen continuamente los riesgos introducidos por las desviaciones de los procedimientos recomendados de seguridad o las limitaciones de diseño del sistema. Mediante la realización de análisis de riesgos dirigidos al menos anualmente en los que faltan controles, cuando las restricciones tecnológicas crean vulnerabilidades y, en respuesta a incidentes de seguridad sospechosos o confirmados, la organización puede identificar debilidades y exposiciones. Esto permite tomar decisiones fundamentadas basadas en riesgos sobre la priorización de los esfuerzos de corrección y la implementación de controles compensadores para minimizar la probabilidad y el impacto de la explotación. El objetivo es proporcionar diligencia, orientación y pruebas continuas de que las lagunas conocidas se abordan de forma consciente del riesgo en lugar de ignorarse indefinidamente. La realización de estas evaluaciones de riesgo dirigidas demuestra el compromiso de la organización con la mejora proactiva de la posición de seguridad a lo largo del tiempo.
Directrices: evaluación anual
Las pruebas pueden ser por medio del seguimiento de versiones o pruebas con fecha. Se deben proporcionar pruebas que muestren el resultado de la evaluación de riesgos de seguridad de la información y las fechas NOT en el propio proceso de evaluación de riesgos de seguridad de la información.
Evidencia de ejemplo: evaluación anual
En la siguiente captura de pantalla se muestra una reunión de evaluación de riesgos programada cada seis meses.
Estas dos capturas de pantalla siguientes muestran un ejemplo de minutos de reunión de dos evaluaciones de riesgo. La expectativa es que se proporcione un informe o minutos de reunión, o informe de la evaluación de riesgos.
Nota: Esta captura de pantalla muestra un documento de directiva o proceso. La expectativa es que los ISV compartan la documentación real de procedimientos o directivas auxiliares y no solo proporcionen una captura de pantalla.
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 de directivas o procedimientos auxiliares y no simplemente proporcionen una captura de pantalla.
Control Nº 23
Valide que la evaluación de riesgos de seguridad de la información incluye:
Componente del sistema o recurso afectado.
Amenazas y vulnerabilidades, o equivalencia.
Matrices de impacto y probabilidad o equivalentes.
La creación de un registro de riesgo o plan de tratamiento de riesgos.
Intención: evaluación de riesgos
La intención es que la evaluación de riesgos incluya componentes y recursos del sistema, ya que ayuda a identificar los recursos de TI más críticos y su valor. Al identificar y analizar posibles amenazas para la empresa, la organización puede centrarse primero en los riesgos que tienen el mayor impacto potencial y la mayor probabilidad. Comprender el posible impacto en la infraestructura de TI y los costos asociados puede ayudar a la administración a tomar decisiones informadas sobre el presupuesto, las directivas, los procedimientos y mucho más. Una lista de componentes o recursos del sistema que se pueden incluir en la evaluación de riesgos de seguridad son:
Servidores
Databases
Aplicaciones
Redes
Dispositivos de almacenamiento de datos
Contactos
Para administrar eficazmente los riesgos de seguridad de la información, las organizaciones deben realizar evaluaciones de riesgos frente a amenazas para el entorno y los datos, así como contra posibles vulnerabilidades que puedan estar presentes. Esto ayudará a las organizaciones a identificar la infinidad de amenazas y vulnerabilidades que pueden suponer un riesgo significativo. Las evaluaciones de riesgos deben documentar las clasificaciones de impacto y probabilidad, que se pueden usar para identificar el valor de riesgo. Esto se puede usar para priorizar el tratamiento del riesgo y ayudar a reducir el valor general del riesgo. Las evaluaciones de riesgo deben realizarse correctamente para proporcionar un registro de uno de los cuatro tratamientos de riesgo que se están aplicando. Estos tratamientos de riesgo son:
Evitar/finalizar: la empresa puede determinar que el costo de tratar con el riesgo es mayor que los ingresos generados por el servicio. Por lo tanto, la empresa puede optar por dejar de realizar el servicio.
Transferencia o uso compartido: la empresa puede optar por transferir el riesgo a un tercero moviendo el procesamiento a un tercero.
Aceptar, tolerar o conservar: la empresa puede decidir que el riesgo es aceptable. Esto depende en gran medida del apetito de riesgo de las empresas y puede variar según la organización.
Tratar, mitigar o modificar: la empresa decide implementar controles de mitigación para reducir el riesgo a un nivel aceptable.
Directrices: evaluación de riesgos
Las pruebas deben proporcionarse no solo mediante el proceso de evaluación de riesgos de seguridad de la información ya suministrado, sino también el resultado de la evaluación de riesgos (mediante un registro de riesgo o plan de tratamiento de riesgos) para demostrar que el proceso de evaluación de riesgos se está llevando a cabo correctamente. El registro de riesgos debe incluir riesgos, vulnerabilidades, impacto y clasificaciones de probabilidad.
Evidencia de ejemplo: evaluación de riesgos
En la captura de pantalla siguiente se muestra el registro de riesgos que muestra las amenazas y vulnerabilidades que se incluyen. También muestra que se incluyen el impacto y las probabilidades.
Nota: Se debe proporcionar la documentación completa de evaluación de riesgos en lugar de una captura de pantalla. En la siguiente captura de pantalla se muestra un plan de tratamiento de riesgos.
Control Nº 24
Proporcione pruebas de que:
Usted (ISV) tiene procesos de administración de riesgos que evalúan y administran los riesgos asociados con proveedores y asociados empresariales.
Usted (ISV) puede identificar y evaluar los cambios y riesgos que podrían afectar al sistema de controles internos.
Intención: proveedores y asociados
La administración de riesgos de proveedores es la práctica de evaluar las posturas de riesgo de los socios comerciales, proveedores o proveedores de terceros, tanto antes de que se establezca una relación comercial como a lo largo de la duración de la relación. Al administrar los riesgos del proveedor, las organizaciones pueden evitar interrupciones en la continuidad del negocio, evitar impactos financieros, proteger su reputación, cumplir las normativas e identificar y minimizar los riesgos asociados a la colaboración con un proveedor. Para administrar eficazmente los riesgos de los proveedores, es importante contar con procesos que incluyan evaluaciones de diligencia debida, obligaciones contractuales relacionadas con la seguridad y supervisión continua del cumplimiento del proveedor.
Directrices: proveedores y asociados
Se pueden proporcionar pruebas para demostrar el proceso de evaluación de riesgos del proveedor, como la documentación establecida de adquisición y verificación, listas de comprobación y cuestionarios para la incorporación de nuevos proveedores y contratistas, evaluaciones realizadas, comprobaciones de cumplimiento, etc.
Pruebas de ejemplo: proveedores y asociados
En la captura de pantalla siguiente se muestra que el proceso de incorporación y investigación del proveedor se mantiene en Confluence como una tarea JIRA. Para cada nuevo proveedor, se produce una evaluación inicial del riesgo para revisar la posición de cumplimiento. Durante el proceso de adquisición se rellena un cuestionario de evaluación de riesgos, y el riesgo global se determina en función del nivel de acceso a los sistemas y los datos que se proporcionan al proveedor.
En la captura de pantalla siguiente se muestra el resultado de la evaluación y el riesgo general que se identificó en función de la revisión inicial.
Intención: controles internos
El objetivo de este subpunto es reconocer y evaluar los cambios y riesgos que podrían afectar a los sistemas de control internos de una organización para garantizar que los controles internos sigan siendo efectivos con el tiempo. A medida que cambian las operaciones empresariales, es posible que los controles internos ya no sean efectivos. Los riesgos evolucionan con el tiempo y pueden surgir nuevos riesgos que no se consideraron anteriormente. Al identificar y evaluar estos riesgos, puede asegurarse de que los controles internos están diseñados para abordarlos. Esto ayuda a evitar fraudes y errores, mantener la continuidad empresarial y garantizar el cumplimiento normativo.
Directrices: controles internos
Se pueden proporcionar pruebas, como revisar los minutos de reunión y los informes, que pueden demostrar que el proceso de evaluación de riesgos del proveedor se actualiza en un período definido para asegurarse de que los posibles cambios del proveedor se tienen en cuenta y se evalúan.
Evidencia de ejemplo: controles internos
En las capturas de pantalla siguientes se muestra que se realiza una revisión de tres meses de la lista de proveedores y contratistas aprobados para garantizar que sus estándares de cumplimiento y nivel de cumplimiento sean coherentes con la evaluación inicial durante la incorporación.
En la primera captura de pantalla se muestran las directrices establecidas para realizar la evaluación y el cuestionario de riesgo.
En las capturas de pantalla siguientes se muestra la lista aprobada por el proveedor real y su nivel de cumplimiento, la evaluación realizada, el evaluador, el aprobador, etc. Tenga en cuenta que este es solo un ejemplo de una evaluación rudimentaria de riesgos de proveedores diseñada para proporcionar un escenario de línea base para comprender el requisito de control y mostrar el formato de la evidencia esperada. Como ISV, debe proporcionar su propia evaluación de riesgos de proveedor establecida según corresponda a su organización.
Respuesta a incidentes de seguridad
La respuesta a incidentes de seguridad es importante para todas las organizaciones, ya que esto puede reducir el tiempo empleado por una organización que contiene un incidente de seguridad y limitar el nivel de exposición de la organización a la filtración de datos. Al desarrollar un plan de respuesta a incidentes de seguridad completo y detallado, esta exposición se puede reducir desde el momento de la identificación hasta el momento de la contención.
Un informe de IBM titulado "Costo de un informe de vulneración de datos 2020" destaca que, en promedio, el tiempo necesario para contener una vulneración fue de 73 días. Además, el mismo informe identifica el mayor ahorro de costos para la organización que sufrió una infracción, fue la preparación de respuesta a incidentes, proporcionando un promedio de
Ahorro de costos de 2 000 000 USD. Las organizaciones deben seguir los procedimientos recomendados para el cumplimiento de seguridad mediante marcos estándar del sector como ISO 27001, NIST, SOC 2, PCI DSS, etc.
Control Nº 25
Proporcione el plan o procedimiento de respuesta a incidentes de seguridad (IRP) ratificado que describa cómo responde su organización a los incidentes, que muestra cómo se mantiene y que incluye:
detalles del equipo de respuesta a incidentes, incluida la información de contacto,
un plan de comunicación interno durante el incidente y la comunicación externa a las partes pertinentes, como las partes interesadas clave, las marcas de pago y los adquirentes, los organismos reguladores (por ejemplo, 72 horas para el RGPD), las autoridades de supervisión, los directores, los clientes,
pasos para actividades como la clasificación de incidentes, la contención, la mitigación, la recuperación y la vuelta a las operaciones empresariales normales en función del tipo de incidente.
Intención: Plan de respuesta de incesto (IRP)
La intención de este control es asegurarse de que haya un plan de respuesta a incidentes (IRP) documentado formalmente que incluya un equipo de respuesta a incidentes designado con roles, responsabilidades e información de contacto claramente documentados. El IRP debe proporcionar un enfoque estructurado para administrar incidentes de seguridad desde la detección hasta la resolución, incluida la clasificación de la naturaleza del incidente, el impacto inmediato, la mitigación de los riesgos, la recuperación del incidente y la restauración de operaciones empresariales normales. Cada paso debe estar bien definido, con protocolos claros, para asegurarse de que las acciones realizadas están alineadas con las estrategias de administración de riesgos y las obligaciones de cumplimiento de la organización.
La especificación detallada del equipo de respuesta a incidentes en el IRP garantiza que cada miembro del equipo comprenda su rol en la administración del incidente, lo que permite una respuesta coordinada y eficaz. Al tener un IRP en su lugar, una organización puede administrar una respuesta a incidentes de seguridad de forma más eficaz, lo que en última instancia puede limitar la exposición a la pérdida de datos de la organización y reducir los costos del riesgo.
Las organizaciones pueden tener obligaciones de notificación de incumplimiento basadas en el país o los países en los que operan (por ejemplo, el RGPD del Reglamento General de Protección de Datos) o en función de la funcionalidad que se ofrezca (por ejemplo, PCI DSS si se tratan los datos de pago). El error de notificación oportuna puede conllevar graves ramificaciones; por lo tanto, para garantizar que se cumplan las obligaciones de notificación, los planes de respuesta a incidentes deben incluir un proceso de comunicación que incluya la comunicación con todas las partes interesadas, los procesos de comunicación de los medios de comunicación y quién puede y no puede hablar con los medios de comunicación.
Directrices: controles internos
Proporcione la versión completa del plan o procedimiento de respuesta a incidentes. El plan de respuesta a incidentes debe incluir una sección que cubra el proceso de control de incidentes desde la identificación hasta la resolución y un proceso de comunicaciones documentado.
Evidencia de ejemplo: controles internos
En la captura de pantalla siguiente se muestra el inicio del plan de respuesta a incidentes de Contoso.
Nota: Como parte del envío de pruebas, debe proporcionar todo el plan de respuesta a incidentes.
Evidencia de ejemplo: controles internos
En la captura de pantalla siguiente se muestra un extracto del plan de respuesta a incidentes que muestra el proceso de comunicación.
Control Nº 26
Proporcione pruebas que muestren lo siguiente:
Todos los miembros del equipo de respuesta a incidentes han recibido formación anual que les permite responder a incidentes.
Intención: entrenamiento
Cuanto más tiempo tarde una organización en contener un riesgo, mayor será el riesgo de filtración de datos, lo que podría dar lugar a un mayor volumen de datos filtrados y mayor será el costo general del riesgo. Es importante que los equipos de respuesta a incidentes de la organización estén equipados para responder a los incidentes de seguridad de forma oportuna. Al realizar entrenamientos regulares y realizar ejercicios de mesa, el equipo está preparado para controlar los incidentes de seguridad de forma rápida y eficaz. Este entrenamiento debe abarcar diversos aspectos, como la identificación de posibles amenazas, acciones de respuesta inicial, procedimientos de escalamiento y estrategias de mitigación a largo plazo.
La recomendación es llevar a cabo tanto entrenamiento interno de respuesta a incidentes para el equipo de respuesta a incidentes como para llevar a cabo ejercicios normales de tabletop, que deben vincularse al riesgo de seguridad de la información.
para identificar los incidentes de seguridad que tienen más probabilidades de producirse. El ejercicio de mesa debe simular escenarios reales para probar y mejorar las capacidades del equipo para reaccionar bajo presión. Al hacerlo, la organización puede asegurarse de que su personal sabe cómo controlar correctamente una vulneración de seguridad o un ciberataque. Y el equipo sabrá qué pasos debe seguir para contener e investigar rápidamente los incidentes de seguridad más probables.
Directrices: entrenamiento
Se deben proporcionar pruebas que demuestren que la formación se ha llevado a cabo mediante el uso compartido del contenido de entrenamiento, y registros que muestran quién asistió (que debe incluir todo el equipo de respuesta a incidentes). Como alternativa, o también, registros que muestran que se ha llevado a cabo un ejercicio de mesa. Todo esto debe haberse completado en un período de 12 meses a partir del momento en que se presenten las pruebas.
Evidencia de ejemplo: entrenamiento
Contoso llevó a cabo un ejercicio de tabla de respuesta a incidentes mediante una empresa de seguridad externa. A continuación se muestra un ejemplo del informe generado como parte de la consultoría.
Nota: El informe completo tendría que compartirse. Este ejercicio también podría llevarse a cabo internamente, ya que no hay ningún requisito de Microsoft 365 para que lo lleve a cabo una empresa de terceros.
Nota: El informe completo tendría que compartirse. Este ejercicio también podría llevarse a cabo internamente, ya que no hay ningún requisito de Microsoft 365 para que lo lleve a cabo una empresa de terceros.
Control Nº 27
Proporcione pruebas de que:
La estrategia de respuesta a incidentes y la documentación complementaria se revisan y actualizan en función de lo siguiente:
lecciones aprendidas de un ejercicio de mesa
lecciones aprendidas al responder a un incidente
cambios organizativos
Intención: revisiones del plan
Con el tiempo, el plan de respuesta a incidentes debe evolucionar en función de los cambios de la organización o en función de las lecciones aprendidas al aplicar el plan. Los cambios en el entorno operativo pueden requerir cambios en el plan de respuesta a incidentes, ya que las amenazas pueden cambiar o los requisitos normativos pueden cambiar. Además, a medida que se realizan ejercicios de tabletop y respuestas reales a incidentes de seguridad, esto a menudo puede identificar áreas del plan que se pueden mejorar. Esto debe integrarse en el plan y la intención de este control es asegurarse de que se incluye este proceso. El objetivo de este control es exigir la revisión y actualización de la estrategia de respuesta a incidentes de la organización y la documentación complementaria basada en tres desencadenadores distintos:
Una vez realizados los ejercicios simulados para probar la eficacia de su estrategia de respuesta a incidentes, las brechas o áreas identificadas para mejorar deben incorporarse inmediatamente al plan de respuesta a incidentes existente.
Un incidente real proporciona información valiosa sobre los puntos fuertes y débiles de la estrategia de respuesta actual. Si se produce un incidente, se debe realizar una revisión posterior al incidente para capturar estas lecciones, que se deben usar para actualizar la estrategia y los procedimientos de respuesta.
Cualquier cambio significativo dentro de la organización, como fusiones, adquisiciones o cambios en el personal clave, debe desencadenar una revisión de la estrategia de respuesta a incidentes. Estos cambios organizativos pueden introducir nuevos riesgos o cambiar los existentes, y el plan de respuesta a incidentes debe actualizarse en consecuencia para que siga siendo efectivo.
Directrices: revisiones del plan
Esto se demostrará a menudo mediante la revisión de los resultados de incidentes de seguridad o ejercicios de tabletop en los que se han identificado las lecciones aprendidas y se ha producido una actualización del plan de respuesta a incidentes. El plan debe mantener un registro de cambios, que también debe hacer referencia a los cambios que se implementaron en función de las lecciones aprendidas o de los cambios de la organización.
Evidencia de ejemplo: revisiones del plan
Las capturas de pantalla siguientes proceden del plan de respuesta a incidentes proporcionado, que incluye una sección sobre la actualización en función de las lecciones aprendidas o de los cambios de la organización.
Nota: 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.
Plan de continuidad empresarial y plan de recuperación ante desastres
El planeamiento de la continuidad empresarial y el planeamiento de la recuperación ante desastres son dos componentes críticos de la estrategia de administración de riesgos de una organización. El planeamiento de continuidad empresarial es el proceso de crear un plan para garantizar que las funciones empresariales esenciales puedan seguir funcionando durante y después de un desastre, mientras que el planeamiento de la recuperación ante desastres es el proceso de crear un plan para recuperarse de un desastre y restaurar las operaciones empresariales normales lo antes posible. Ambos planes se complementan entre sí: debe tener ambos para soportar los desafíos operativos provocados por desastres o interrupciones inesperadas. Estos planes son importantes porque ayudan a garantizar que una organización puede seguir funcionando durante un desastre, proteger su reputación, cumplir los requisitos legales, mantener la confianza del cliente, administrar los riesgos de forma eficaz y mantener a los empleados seguros.
Control Nº 28
Proporcione pruebas que demuestren lo siguiente:
La documentación existe y se mantiene, que describe el plan de continuidad empresarial e incluye:
detalles del personal pertinente, incluidos sus roles y responsabilidades
funciones empresariales con los requisitos y objetivos de contingencia asociados
procedimientos de copia de seguridad del sistema y de datos, configuración y programación/retención
prioridad de recuperación y objetivos de período de tiempo
un plan de contingencia que detalla las acciones, los pasos y los procedimientos que se deben seguir para devolver a la operación sistemas de información críticos, funciones empresariales y servicios en caso de una interrupción inesperada y no programada
un proceso establecido que abarca la eventual restauración completa del sistema y el retorno al estado original
Intención: plan de continuidad empresarial
La intención de este control es asegurarse de que se incluye en el plan de continuidad empresarial una lista claramente definida del personal con roles y responsabilidades asignados. Estos roles son fundamentales para la activación y ejecución efectivas del plan durante un incidente.
Directrices: plan de continuidad empresarial
Proporcione la versión completa del plan o procedimiento de recuperación ante desastres, que debe incluir secciones que cubran el esquema procesado en la descripción del control. 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 o capturas de pantalla de los procesos.
Evidencia de ejemplo: plan de continuidad empresarial
En las capturas de pantalla siguientes se muestra un extracto de un plan de continuidad empresarial y que existe y se mantiene.
Nota: En estas capturas de pantalla se muestran instantáneas de un documento de directiva o proceso, la expectativa es que los ISV compartan la documentación real de directivas o procedimientos auxiliares y no simplemente proporcionen una captura de pantalla.
En las capturas de pantalla siguientes se muestra un extracto de la directiva donde se describe la sección "Personal clave", incluido el equipo pertinente, los detalles de contacto y los pasos que se deben seguir.
Intención: priorización
El propósito de este control es documentar y priorizar las funciones empresariales según su importancia crítica. Esto debe ir acompañado de un esquema de los requisitos de contingencia correspondientes necesarios para mantener o restaurar rápidamente cada función durante una interrupción no planeada.
Directrices: priorización
Proporcione la versión completa del plan o procedimiento de recuperación ante desastres, que debe incluir secciones que cubran el esquema procesado en la descripción del control. 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 o capturas de pantalla de los procesos.
Evidencia de ejemplo: priorización
En las capturas de pantalla siguientes se muestra un extracto de un plan de continuidad empresarial y un esquema de las funciones empresariales y su nivel de importancia crítica, así como si existen planes de contingencia.
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 de directivas o procedimientos auxiliares y no simplemente proporcionen una captura de pantalla.
Intención: copias de seguridad
El objetivo de este subpunto es mantener procedimientos documentados para realizar copias de seguridad de los sistemas y datos esenciales. La documentación también debe especificar los valores de configuración, así como las directivas de retención y programación de copia de seguridad, para asegurarse de que los datos son tanto actuales como recuperables.
Directrices: copias de seguridad
Proporcione la versión completa del plan o procedimiento de recuperación ante desastres, que debe incluir secciones que cubran el esquema procesado en la descripción del control. 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 o capturas de pantalla de los procesos.
Evidencia de ejemplo: copias de seguridad
En las capturas de pantalla siguientes se muestra el extracto del plan de recuperación ante desastres de Contoso y que existe una configuración de copia de seguridad documentada para cada sistema. Tenga en cuenta que en la siguiente captura de pantalla que también se describe la programación de copia de seguridad, tenga en cuenta que, en este ejemplo, la configuración de copia de seguridad se describe como parte del plan de recuperación ante desastres, ya que los planes de continuidad empresarial y recuperación ante desastres funcionan conjuntamente.
Nota: En esta captura de pantalla se muestra una instantánea de un documento de directiva o procedimiento, la expectativa es que los ISV compartan la documentación real de directivas o procedimientos auxiliares y no simplemente proporcionen una captura de pantalla.
Intención: escalas de tiempo
Este control tiene como objetivo establecer escalas de tiempo prioritarias para las acciones de recuperación. Estos objetivos de tiempo de recuperación (OCR) deben estar alineados con el análisis de impacto empresarial y deben definirse claramente para que el personal comprenda primero qué sistemas y funciones deben restaurarse.
Directrices: escalas de tiempo
Proporcione la versión completa del plan o procedimiento de recuperación ante desastres, que debe incluir secciones que cubran el esquema procesado en la descripción del control. 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 o capturas de pantalla de los procesos.
Evidencia de ejemplo: escalas de tiempo
En la captura de pantalla siguiente se muestra la continuación de las funciones empresariales y la clasificación de la importancia crítica, así como el objetivo de tiempo de recuperación (RTO) establecido.
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 de directivas o procedimientos auxiliares y no simplemente proporcionen una captura de pantalla.
Intención: recuperación
Este control pretende proporcionar un procedimiento paso a paso que se va a seguir para devolver los sistemas de información críticos, las funciones empresariales y los servicios al estado operativo. Esto debe ser lo suficientemente detallado como para guiar la toma de decisiones en situaciones de alta presión, donde las acciones rápidas y eficaces son esenciales.
Directrices: recuperación
Proporcione la versión completa del plan o procedimiento de recuperación ante desastres, que debe incluir secciones que cubran el esquema procesado en la descripción del control. 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 o capturas de pantalla de los procesos.
Evidencia de ejemplo: recuperación
En las capturas de pantalla siguientes se muestra el extracto de nuestro plan de recuperación ante desastres y que existe un plan de recuperación documentado para cada sistema y función empresarial, tenga en cuenta que, en este ejemplo, el procedimiento de recuperación del sistema forma parte del plan de recuperación ante desastres, ya que la continuidad empresarial y los planes de recuperación ante desastres funcionan conjuntamente para lograr la recuperación y restauración completa.
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 de directivas o procedimientos auxiliares y no simplemente proporcionen una captura de pantalla.
Intención: validación
Este punto de control tiene como objetivo garantizar que el plan de continuidad empresarial incluya un proceso estructurado para guiar a la organización en la restauración de los sistemas a su estado original una vez que se ha administrado la crisis. Esto incluye los pasos de validación para asegurarse de que los sistemas están totalmente operativos y han conservado su integridad.
Directrices: validación
Proporcione la versión completa del plan o procedimiento de recuperación ante desastres, que debe incluir secciones que cubran el esquema procesado en la descripción del control. 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 o capturas de pantalla de los procesos.
Prueba de ejemplo: validación
En la captura de pantalla siguiente se muestra el proceso de recuperación descrito en la directiva del plan de continuidad empresarial y los pasos o acciones que se van a realizar.
Nota: En esta captura de pantalla se muestra una instantánea de un documento de directiva o procedimiento, la expectativa es que los ISV compartan la documentación real de directivas o procedimientos auxiliares y no simplemente proporcionen una captura de pantalla.
Control Nº 29
Proporcione pruebas que demuestren lo siguiente:
La documentación existe y se mantiene, que describe el plan de recuperación ante desastres e incluye como mínimo:
detalles del personal pertinente, incluidos sus roles y responsabilidades
funciones empresariales con los requisitos y objetivos de contingencia asociados
procedimientos de copia de seguridad del sistema y de datos, configuración y programación/retención
prioridad de recuperación y objetivos de período de tiempo
un plan de contingencia que detalla las acciones, los pasos y los procedimientos que se deben seguir para devolver a la operación sistemas de información críticos, funciones empresariales y servicios en caso de una interrupción inesperada y no programada
un proceso establecido que abarca la eventual restauración completa del sistema y el retorno al estado original
Intención: DRP
El objetivo de este control es tener roles y responsabilidades bien documentados para cada miembro del equipo de recuperación ante desastres. También se debe describir un proceso de escalado para asegurarse de que el personal adecuado eleva y resuelve rápidamente los problemas durante un escenario de desastre.
Directrices: DRP
Proporcione la versión completa del plan o procedimiento de recuperación ante desastres, que debe incluir secciones que cubran el esquema procesado en la descripción del control. 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 o capturas de pantalla de los procesos.
Evidencia de ejemplo: DRP
En las capturas de pantalla siguientes se muestra el extracto de un plan de recuperación ante desastres y que existe y se mantiene.
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 de directivas o procedimientos auxiliares y no simplemente proporcionen una captura de pantalla.
En la captura de pantalla siguiente se muestra un extracto de la directiva en la que se describe el "Plan de contingencia", incluido el equipo pertinente, los detalles de contacto y los pasos de escalación.
Intención: inventario
La intención de este control es mantener una lista de inventario actualizada de todos los sistemas de información que son cruciales para respaldar las operaciones empresariales. Esta lista es fundamental para comprender qué sistemas deben priorizarse durante un esfuerzo de recuperación ante desastres.
Directrices: inventario
Proporcione la versión completa del plan o procedimiento de recuperación ante desastres, que debe incluir secciones que cubran el esquema procesado en la descripción del control. 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 o capturas de pantalla de los procesos.
Evidencia de ejemplo: inventario
En las capturas de pantalla siguientes se muestra el extracto de un DRP y que existe un inventario de sistemas críticos y su nivel de importancia crítica, así como las funciones del sistema.
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 de directivas o procedimientos auxiliares y no simplemente proporcionen una captura de pantalla.
En la captura de pantalla siguiente se muestra la definición de clasificación y de importancia crítica del servicio.
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 de directivas o procedimientos auxiliares y no simplemente proporcionen una captura de pantalla.
Intención: copias de seguridad
Este control requiere que se produzcan procedimientos bien definidos para las copias de seguridad del sistema y de los datos. Estos procedimientos deben describir la frecuencia, la configuración y las ubicaciones de las copias de seguridad para garantizar que todos los datos críticos se puedan restaurar en caso de error o desastre.
Directrices: copias de seguridad
Proporcione la versión completa del plan o procedimiento de recuperación ante desastres, que debe incluir secciones que cubran el esquema procesado en la descripción del control. 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 o capturas de pantalla de los procesos.
Evidencia de ejemplo: copias de seguridad
En las capturas de pantalla siguientes se muestra el extracto de un plan de recuperación ante desastres y que existe una configuración de copia de seguridad documentada para cada sistema. Observe a continuación que también se describe la programación de copia de seguridad.
Nota: En esta captura de pantalla se muestra una instantánea de un documento de directiva o proceso, la expectativa es que los ISV compartan la documentación real de directivas o procedimientos auxiliares y no simplemente proporcionen una captura de pantalla.
Intención: recuperación
Este control requiere un plan de recuperación completo que describa los procedimientos paso a paso para restaurar los datos y los sistemas vitales. Esto sirve como hoja de ruta para el equipo de recuperación ante desastres y garantiza que todas las acciones de recuperación sean premeditadas y eficaces en la restauración de las operaciones empresariales.
Directrices: recuperación
Proporcione la versión completa del plan o procedimiento de recuperación ante desastres, que debe incluir secciones que cubran el esquema procesado en la descripción del control. 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 o capturas de pantalla de los procesos.
Evidencia de ejemplo: recuperación
En las capturas de pantalla siguientes se muestra el extracto de un plan de recuperación ante desastres y que existen instrucciones y pasos de reemplazo de equipos y recuperación del sistema, así como el procedimiento de recuperación que incluye los períodos de tiempo de recuperación, las acciones que se deben realizar para restaurar la infraestructura en la nube, etc.
Nota: En esta captura de pantalla se muestra una instantánea de un documento de directiva o proceso, la expectativa es que los ISV compartan la documentación real de directivas o procedimientos auxiliares y no simplemente proporcionen una captura de pantalla.
Control Nº 30
Proporcione pruebas que demuestren lo siguiente:
El plan de continuidad empresarial y el plan de recuperación ante desastres se revisan al menos cada 12 meses para asegurarse de que sigue siendo válido y eficaz durante situaciones adversas y se actualiza en función de lo siguiente:
Revisión anual del plan.
Todo el personal pertinente recibe capacitación sobre sus roles y responsabilidades asignadas en los planes de contingencia.
Los planes se prueban mediante ejercicios de continuidad empresarial o recuperación ante desastres.
Los resultados de las pruebas se documentan, incluidas las lecciones aprendidas de ejercicios o cambios organizativos.
Intención: revisión anual
El propósito de este control es garantizar que los planes de continuidad empresarial y recuperación ante desastres se revisen anualmente. La revisión debe confirmar que los planes siguen siendo eficaces, precisos y alineados con los objetivos empresariales actuales y las arquitecturas tecnológicas.
Intención: entrenamiento anual
Este control exige que todas las personas con roles designados en los planes de continuidad empresarial y recuperación ante desastres reciban la formación adecuada anualmente. El objetivo es asegurarse de que son conscientes de sus responsabilidades y capaces de ejecutarlas de forma eficaz en caso de desastre o interrupción del negocio.
Intención: ejercicios
La intención aquí es validar la eficacia de los planes de continuidad empresarial y recuperación ante desastres a través de ejercicios del mundo real. Estos ejercicios deben diseñarse para simular varias condiciones adversas para probar el grado de mantenimiento o restauración de las operaciones empresariales por parte de la organización.
Intención: análisis
El punto de control final tiene como objetivo una documentación exhaustiva de todos los resultados de las pruebas, incluido un análisis de lo que funcionó bien y lo que no. Las lecciones aprendidas deben integrarse de nuevo en los planes, y las deficiencias deben abordarse inmediatamente para mejorar la resistencia de la organización.
Directrices: revisiones
Se deben proporcionar pruebas como informes, notas de reunión y resultados de los ejercicios anuales de continuidad empresarial y planes de recuperación ante desastres para su revisión.
Pruebas de ejemplo: revisiones
En las capturas de pantalla siguientes se muestra una salida de informe de un simulacro de plan de continuidad empresarial y recuperación ante desastres (ejercicio) en el que se estableció un escenario para permitir al equipo implementar el plan de continuidad empresarial y recuperación ante desastres y explorar la situación hasta la restauración correcta de las funciones empresariales y la operación del sistema.
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 directivas o procedimientos auxiliares y no simplemente proporcionen una captura de pantalla.
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 directivas o procedimientos auxiliares y no simplemente proporcionen una captura de pantalla.