Detección de vulnerabilidades de un clúster regulado de AKS para PCI-DSS 3.2.1 (parte 5 de 9)

En este artículo se describen las consideraciones para un clúster de Azure Kubernetes Service (AKS) configurado de acuerdo con el estándar de seguridad de datos del sector de tarjetas de pago (PCI-DSS 3.2.1).

Este artículo forma parte de una serie. Lea la introducción.

Igual que cualquier solución en la nube, una carga de trabajo de PCI está sujeta a amenazas de red, identidad y datos. Los ejemplos habituales de orígenes que aprovechan las vulnerabilidades de la carga de trabajo y del sistema son los virus o las actualizaciones de software que generan resultados no deseados. Detecte pronto las amenazas y responda con mitigación de forma oportuna. Cree alertas críticas para las actividades de carga de trabajo y extienda esas alertas a los procesos principales del sistema. Las herramientas de supervisión de integridad de archivos (FIM) o antivirus deben estar siempre en ejecución. Tenga un plan de respuesta responsable y un equipo que investigue las alertas y tome medidas.

Mantenimiento de un programa de administración de vulnerabilidades

Requisito 5: Protección de todos los sistemas frente a malware y actualización periódica de los programas o software antivirus

Compatibilidad con características de AKS

AKS no se comporta como un host de aplicaciones tradicional. Las máquinas virtuales de nodo de un clúster de AKS tienen una exposición limitada y están diseñadas para que no se acceda a ellas de forma directa. Dado que las máquinas virtuales de nodo no equivalen a las máquinas virtuales tradicionales, no puede usar las herramientas de máquina virtual comunes. Por lo tanto, las recomendaciones de esta sección se aplican a través de construcciones nativas de Kubernetes. La aplicación de estos requisitos directamente en el nivel de máquina virtual puede hacer que el clúster no sea compatible.

Tendrá que implementar software antimalware de su elección en DaemonSets que se ejecutará en un pod en cada nodo.

Sus responsabilidades

Asegúrese de que el software está especializado en Kubernetes y contenedores. Hay varias opciones de software de terceros. Entre las opciones más populares se incluyen Prisma Cloud y Aquasec. También hay opciones de código abierto, como Falco. Es su responsabilidad asegurarse de que existen procesos para garantizar que el software de terceros está actualizado. Además, la supervisión y las alertas de las soluciones son responsabilidad suya.

Requisito 6: Desarrollo y mantenimiento de aplicaciones y sistemas seguros

Compatibilidad con características de AKS

Al igual que otros servicios de Azure, AKS sigue los procesos de Microsoft SDL (Ciclo de vida de desarrollo de seguridad) para la seguridad a lo largo de las fases del proceso de desarrollo. Se analizan varios componentes desde las primeras fases de desarrollo y se resuelven las brechas de seguridad lo antes posible.

Las imágenes de AKS siguen el enfoque del SLA de FedRAMP, que requiere que las vulnerabilidades de las imágenes se revisen en un plazo de 30 días. Para aplicar este requisito, todas las imágenes se sanean mediante una canalización de DevSecOps.

Semanalmente, AKS proporciona nuevas imágenes para los grupos de nodos. Es su responsabilidad aplicarlas para garantizar la aplicación de revisiones y la actualización de los nodos de trabajo de los conjuntos de escalado de máquinas virtuales. Para más información, consulte Actualización de la imagen de nodo de Azure Kubernetes Service (AKS).

Para el plano de control de AKS, AKS instala o actualiza las revisiones de seguridad. Se actualizan cada 24 horas.

El plano de control y los nodos de trabajo de AKS se protegen mediante los puntos de referencia de Center for Internet Security (CIS), específicamente AKS CIS, Ubuntu CIS y Windows CIS.

AKS se integra con Azure Container Registry. Use Azure Container Registry con características de análisis continuo en Microsoft Defender for Cloud para identificar imágenes y aplicaciones vulnerables en varios niveles de riesgo. Para obtener información sobre el análisis de imágenes y el control de riesgos, consulte Microsoft Defender para contenedores.

Sus responsabilidades

Requisito 5.1

Implemente software antivirus en todos los sistemas que suelen verse afectados por software malicioso (en particular equipos personales y servidores).

Sus responsabilidades

Es su responsabilidad proteger la carga de trabajo, la infraestructura y las canalizaciones de implementación mediante la elección de un software antimalware adecuado.

Dado que el acceso a las máquinas virtuales del nodo de AKS está restringido, proteja el sistema en las capas que pueden insertar malware en las máquinas virtuales del nodo. Incluya la detección y prevención en los nodos de clúster, imágenes de contenedor e interacciones del entorno de ejecución con el servidor de API de Kubernetes. Además del clúster, proteja los componentes que interactúan con el clúster y en los que se puede instalar software antivirus de forma tradicional:

• Cuadros de salto
• Agentes de compilación

Alinee las actividades de examen con el Ciclo de vida de desarrollo de seguridad de Microsoft (SDL). Seguir el SDL garantiza que se inicie el examen de varios componentes de la arquitectura en las primeras fases del desarrollo y que las brechas de seguridad se resuelvan lo antes posible.

Requisito 5.1.1

Asegúrese de que los programas antivirus puedan detectar, eliminar y proteger frente a todos los tipos de software malicioso conocido.

Sus responsabilidades

Obtenga información sobre el conjunto de características de cada oferta de software y la profundidad del análisis que puede realizar. El software debe bloquear las amenazas comunes y supervisar las nuevas amenazas. Asegúrese de que el software se actualiza periódicamente, se prueba y se reemplaza si no es adecuado. Analice el software desarrollado por proveedores de confianza.

• Herramientas de supervisión que detectan vulnerabilidades del clúster.

  En AKS, no puede ejecutar soluciones de máquina virtual tradicionales basadas en agente directamente en las máquinas virtuales de nodo. Tendrá que implementar software antimalware en DaemonSets que se ejecutará en un pod en cada nodo.

  Elija software especializado en Kubernetes y cargas de trabajo contenedorizadas. Hay varias opciones de software de terceros. Entre las opciones más populares se incluyen Prisma Cloud y Aquasec. También hay opciones de código abierto, como Falco.

  Cuando se implementan, se ejecutan como agentes en el clúster que analiza todos los grupos de nodos de usuario y del sistema. Aunque AKS usa grupos de nodos del sistema para sus archivos binarios del sistema de runtime, el proceso subyacente sigue siendo su responsabilidad.

  El propósito de ejecutar el agente es detectar actividades de clúster inusuales. Por ejemplo, ¿intenta una aplicación llamar al servidor de API? Algunas soluciones generan un registro de llamadas API entre pods, informes y alertas. Asegúrese de revisar esos registros y realizar las acciones necesarias.

  Instale agentes de seguridad inmediatamente después del arranque del clúster para minimizar las brechas no supervisadas entre la implementación del clúster y los recursos de AKS.

  Los agentes de seguridad se ejecutan con privilegios elevados y examinan todo lo que se ejecuta en el clúster y no solo la carga de trabajo. No deben convertirse en un origen de filtración de datos. Además, los ataques de la cadena de suministro son comunes para los contenedores. Use estrategias de defensa en profundidad y asegúrese de que el software y todas las dependencias son de confianza.

  Ejecute también software antivirus en recursos externos que participan en operaciones de clúster. Algunos ejemplos incluyen jumpboxes, agentes de compilación e imágenes de contenedor que interactúan con el clúster.

  Cuando el agente realiza los exámenes, no debe bloquear ni interferir con las operaciones críticas del clúster, como al bloquear archivos. Una configuración incorrecta puede causar problemas de estabilidad y podría dejar el clúster sin soporte técnico.

  Importante

  La implementación de referencia proporciona una implementación de marcador de posición DaemonSet para ejecutar un agente antimalware. El agente se ejecutará en cada máquina virtual de nodo del clúster. Coloque su elección de software antimalware en esta implementación.

• Mantenimiento de la seguridad de los contenedores. Ejecute herramientas de análisis de contenedores en la canalización para detectar amenazas que puedan surgir mediante imágenes de contenedor, como el examen de vulnerabilidades de CI/CD en Microsoft Defender para contenedores. Entre las opciones de terceros se incluyen Trivy y Clair. Cuando cree imágenes, procure siempre que sean imágenes "distroless" (sin administrador de paquetes, shell o sistema operativo). Estas imágenes solo contienen los archivos binarios esenciales en la imagen base de Linux y reducen el área de superficie para los ataques. Use una solución de examen continuo, como la evaluación de vulnerabilidades en Microsoft Defender para contenedores, para el examen continuo de imágenes que ya están en reposo en los repositorios.

Requisito 5.1.2

En el caso de los sistemas que no se suelen ver afectados por software malicioso o ser su objetivo, realice evaluaciones periódicas para identificar y evaluar las amenazas de malware, en constante evolución, y confirme si siguen sin necesitar software antivirus.

Sus responsabilidades

Las vulnerabilidades comunes pueden afectar a los componentes fuera del clúster. Realice un seguimiento de las vulnerabilidades de seguridad mediante la observación de CVE y otras alertas de seguridad desde la plataforma de Azure. Busque las actualizaciones de Azure para ver las nuevas características que pueden detectar vulnerabilidades y ejecutar soluciones antivirus en servicios hospedados en Azure.

Por ejemplo, el almacenamiento de blobs debe tener un filtrado de reputación de malware para detectar cargas sospechosas. Microsoft Defender para Storage incluye el filtrado de reputación de malware. Además, considere si se necesita una solución antivirus para este tipo de servicio.

Requisito 5.2

Asegúrese de que todos los mecanismos antivirus se mantengan de la manera siguiente:

• Deben estar actualizados.
• Deben realizarse análisis periódicos.
• Generar registros de auditoría y conservarlos de acuerdo con el requisito 10.7 de PCI DSS.

Sus responsabilidades

• Asegúrese de que el clúster está protegido frente a nuevos ataques mediante la versión más reciente del software antivirus. Hay dos tipos de actualizaciones que se deben considerar:
  • El software antivirus debe mantenerse al día con las actualizaciones de características más recientes. Una manera es programar actualizaciones como parte de las actualizaciones de la plataforma.
  • Las actualizaciones de inteligencia de seguridad se deben aplicar en cuanto estén disponibles para detectar e identificar las amenazas más recientes. Opte por las actualizaciones automáticas.
• Valide que los exámenes de vulnerabilidades se estén ejecutando, según lo programado.
• Retenga los registros que se generan como resultado del análisis, que indica componentes correctos e incorrectos. El período de retención recomendado se proporciona en el requisito 10.7, que es un año.
• Disponga de un proceso que evalúe las prioridades y corrija los problemas detectados.

Para obtener información sobre cómo se aplican las actualizaciones de antivirus de Microsoft Defender para punto de conexión, consulte Inteligencia de seguridad y actualizaciones de productos del antivirus Microsoft Defender.

Requisito 5.3

Las características antivirus se deben ejecutar activamente y los usuarios no deben poder deshabilitarlas ni modificarlas. Excepto cuando lo autorice la administración caso a caso durante un período de tiempo limitado.

Sus responsabilidades

Usted es responsable de configurar la supervisión y las alertas del agente de seguridad. Cree alertas críticas no solo para la carga de trabajo, sino también para los procesos principales del sistema. El agente debe estar siempre en ejecución. Responda a las alertas generadas por el software antimalware.

• Mantenga una pista de registro de las actividades de análisis. Asegúrese de que el proceso de examen no registre datos de los titulares de las tarjetas extraídos del disco o la memoria.
• Establezca alertas para las actividades que pueden provocar un error inesperado en el cumplimiento. Las alertas no deben desactivarse accidentalmente.
• Restrinja los permisos para modificar la implementación del agente y otras herramientas de seguridad críticas. Mantenga esos permisos separados de los permisos de implementación de la carga de trabajo.
• No implemente cargas de trabajo si los agentes de seguridad no se ejecutan según lo previsto.

Requisito 5.4

Compruebe que las directivas de seguridad y los procedimientos operativos para proteger los sistemas frente al malware estén documentados, en uso, y que se hayan comunicado a todas las partes afectadas.

Sus responsabilidades

Es crítico mantener una documentación exhaustiva sobre el proceso y las directivas, especialmente los detalles sobre la solución antivirus que se usa para proteger el sistema. Incluya información como dónde se mantienen en el ciclo del producto las actualizaciones de inteligencia de seguridad, la frecuencia de los análisis y la información sobre las funcionalidades de análisis en tiempo real.

Tenga directivas de retención para almacenar registros. Puede que quiera disponer de almacenamiento a largo plazo con fines de cumplimiento.

Mantenga documentación sobre los procedimientos operativos estándar para la evaluación y la corrección de problemas. Las personas que operan en entornos regulados deben estar formadas e informadas y se les debe incentivar para respaldar las garantías de seguridad. Es especialmente importante para las personas que forman parte del proceso de aprobación desde la perspectiva de las directivas.

Requisito 6.1

Establezca un proceso para identificar vulnerabilidades de seguridad, mediante el uso de orígenes externos de buena reputación para obtener información sobre las vulnerabilidades de seguridad, y asignar una clasificación de riesgo (por ejemplo, alto, medio o bajo) a las vulnerabilidades de seguridad detectadas recientemente.

Sus responsabilidades

Debe tener procesos que comprueben las vulnerabilidades detectadas y que estén clasificados correctamente. En Microsoft Defender for Cloud se muestran recomendaciones y alertas, basadas en el tipo de recurso, su gravedad y entorno. La mayoría de las alertas tienen tácticas MITRE ATT&CK® que pueden ayudarle a comprender la intención de la cadena de eliminación. Asegúrese de que tiene un plan de corrección para investigar y mitigar el problema.

En AKS, puede usar Azure Container Registry en combinación con el análisis continuo para identificar imágenes y aplicaciones vulnerables en varios niveles de riesgo. Puede ver los resultados en Microsoft Defender for Cloud.

Para obtener más información, consulte Protección de contenedores en Defender for Cloud.

Requisito 6.2

Asegúrese de que todos los componentes del sistema y el software están protegidos frente a vulnerabilidades conocidas mediante la instalación de las actualizaciones de seguridad aplicables proporcionadas por el proveedor. Instale revisiones de seguridad críticas en el primer mes de lanzamiento.

Sus responsabilidades

• Para evitar ataques a la cadena de suministro de proveedores de terceros, asegúrese de que todas las dependencias son de confianza. Es importante que elija proveedores con reputación y de confianza.

• Semanalmente, AKS proporciona nuevas imágenes para los grupos de nodos. Esas imágenes no se aplican automáticamente. Aplíquelas en cuanto estén disponibles. La actualización la puede realizar de forma automática o manual a través de Node Image Update. Para más información, consulte Actualización de la imagen de nodo de Azure Kubernetes Service (AKS).

  Para el plano de control de AKS, AKS instala o actualiza las revisiones de seguridad.

• Cada 24 horas, los nodos de AKS descargan e instalan automáticamente el sistema operativo y las actualizaciones de seguridad, individualmente. El firewall no debe bloquear este tráfico si desea recibir esas actualizaciones.

  Considere la posibilidad de habilitar las funcionalidades de informes en el agente de seguridad para obtener información sobre las actualizaciones aplicadas. Algunas actualizaciones de seguridad requieren un reinicio. Asegúrese de revisar las alertas y tomar medidas para garantizar un tiempo de inactividad mínimo o cero de la aplicación al realizar esos reinicios. Una opción de código abierto para realizar reinicios de forma controlada es Kured (demonio de reinicio de Kubernetes).

• Extienda el proceso de aplicación de revisiones a los recursos fuera del clúster que aprovisiona, como jumpboxes y agentes de compilación.

• Manténgase al día con las versiones compatibles de AKS. Si el diseño usa una versión que ha llegado al final del ciclo de vida, actualice a una versión actual. Para más información, consulte Versiones compatibles de AKS.

Requisito 6.3

Desarrolle aplicaciones de software internas y externas (incluido el acceso administrativo basado en web a las aplicaciones) de forma segura, como sigue:

• De acuerdo con PCI DSS (por ejemplo, registro y autenticación seguros)
• Basadas en estándares o procedimientos recomendados del sector.
• Mediante la incorporación de seguridad de la información a lo largo del ciclo de vida de desarrollo de software que se aplique a todo el software desarrollado internamente, incluido el software a medida o personalizado desarrollado por terceros.

Sus responsabilidades

Integre y priorice las opciones de seguridad como parte del ciclo de vida de la carga de trabajo y las operaciones.

Varios marcos del sector se asignan al ciclo de vida, como el marco de NIST. Las funciones de NIST (identificación, protección, detección, respuesta y recuperación) proporcionan estrategias para controles preventivos en cada fase.

El SDL (ciclo de vida de desarrollo de seguridad) de Microsoft proporciona procedimientos recomendados, herramientas y procesos de seguridad a lo largo de las fases del proceso de desarrollo. Se siguen las prácticas de SDL de Microsoft para todos los servicios de Azure, incluido AKS. También se sigue el marco de Operational Security Assurance (OSA) para los servicios que operan en la nube. Asegúrese de que tiene un proceso similar. Estas prácticas se publican para ayudarle a proteger las aplicaciones.

• SDL de Microsoft
• OSA de Microsoft

Requisito 6.3.1

Elimine las cuentas, los id. de usuario y las contraseñas de aplicaciones en desarrollo, de prueba o personalizadas antes de activar dichas aplicaciones o de que se liberen para los clientes.

Sus responsabilidades

Como parte de la creación del clúster, se crean varios usuarios locales de Kubernetes de forma predeterminada. Esos usuarios no se pueden auditar porque no representan una identidad única. Algunos de ellos tienen privilegios elevados. Deshabilite esos usuarios mediante la característica Deshabilitar cuentas locales de AKS.

Para otras consideraciones, consulte las instrucciones del estándar PCI-DSS 3.2.1 oficial.

Requisito 6.3.2

Revise el código personalizado antes de liberarlo para producción o para los clientes con el fin de identificar cualquier posible vulnerabilidad de codificación (mediante procesos manuales o automatizados) para incluir lo siguiente:

• Los cambios en el código los revisan personas diferentes al autor del código de origen y conocedoras de las técnicas de revisión de código y de los procedimientos de codificación segura.
• Las revisiones del código aseguran que este se desarrolla según las instrucciones de codificación segura.
• Las correcciones correspondientes se implementan antes del lanzamiento.
• La administración revisa y aprueba los resultados de la revisión de código antes del lanzamiento.

Sus responsabilidades

Todo el software instalado en el clúster debe tener su origen en el registro de contenedor. De forma similar al código de la aplicación, haga que los procesos y las personas examinen las imágenes de Azure y de terceros (DockerFile y OCI). Además:

• Empiece a analizar las imágenes de contenedor desde las fases iniciales cuando se cree el clúster. Haga que el proceso de análisis forme parte de las canalizaciones de integración o implementación continuas.

  Asegúrese de que las canalizaciones de implementación contienen puertas de forma que tanto las imágenes de arranque del clúster como la carga de trabajo han pasado a través de una puerta de revisión o cuarentena. Mantenga el historial sobre cómo y qué procesos se usaron antes de que se incorporen los cambios al clúster.

• Reduzca el tamaño de la imagen. Normalmente, las imágenes contienen más archivos binarios de los necesarios. Reducir el tamaño de la imagen no solo tiene ventajas de rendimiento, sino que también limita la superficie de ataque. Por ejemplo, el uso de imágenes sin distribución minimizará la superficie de ataque de las imágenes base de Linux.

• Use herramientas de análisis estático que comprueben la integridad de Dockerfile y los manifiestos. Entre las opciones de terceros se incluyen Dockle y Trivy.

• Use solo imágenes firmadas.

• Comprenda (y acepte) la imagen base proporcionada por Azure y cómo cumple con los puntos de referencia de CIS. Para más información, vea Puntos de referencia de Center for Internet Security (CIS).

Azure Container Registry con análisis continuo en Microsoft Defender for Cloud ayuda a identificar las imágenes vulnerables y los diversos riesgos que pueden suponer para la carga de trabajo. Para más información sobre el análisis de imágenes y el control de riesgos, consulte Seguridad de los contenedores.

Requisito 6.4

Siga los procedimientos y procesos de control de cambios para todos los cambios en los componentes del sistema.

Sus responsabilidades

Asegúrese de documentar los procesos de control de cambios y diseñar las canalizaciones de implementación según esos procesos. Incluya otros procesos para detectar situaciones en las que los procesos y las canalizaciones reales no se alineen.

Requisitos 6.4.1, 6.4.2

• Separe los entornos de desarrollo o de prueba de los entornos de producción y aplique la separación con controles de acceso.
• Separe las obligaciones entre entornos de desarrollo o de prueba y de producción.

Sus responsabilidades

Mantenga separados los entornos y roles de producción y preproducción que funcionan en esos entornos.

• No use el clúster de producción con fines de desarrollo o pruebas. Por ejemplo, no instale el Puente a Kubernetes en los clústeres de producción. Use clústeres dedicados para cargas de trabajo que no son de producción.

• Asegúrese de que los entornos de producción no permitan el acceso de red a entornos de preproducción y viceversa.

• No reutilice las identidades del sistema en entornos de preproducción y producción.

  Use grupos de Microsoft Entra para grupos como administradores de clústeres o entidades de seguridad de canalización. No use grupos generalizados o comunes como controles de acceso. No reutilice esos grupos entre los clústeres de preproducción y producción. Una manera es usar el nombre del clúster (u otro identificador opaco) en el nombre del grupo, para que sea explícito sobre las pertenencias.

  Use los roles de control de acceso basado en rol (RBAC) de Azure adecuadamente entre entornos. Normalmente, se asignan más roles y derechos en entornos de preproducción.

  No se debe conceder acceso en producción a las identidades solo de preproducción (concedidas a canalizaciones o equipos de ingeniería de software). Por el contrario, no se debe conceder acceso a las identidades de solo producción (como las canalizaciones) en clústeres de preproducción.

  No use la misma identidad administrada asignada por el usuario para ningún recurso en preproducción y en producción. Esta recomendación se aplica a todos los recursos que admiten identidades administradas asignadas por el usuario, no solo al recurso implementado en el clúster. Por lo general, los recursos de Azure que requieren identidades deben tener su propia identidad distinta en lugar de compartirla con otros recursos.

• Use el acceso Just-In-Time (JIT) para el acceso con privilegios elevados, incluso en clústeres de preproducción si es posible. Use directivas de acceso condicional en los clústeres de preproducción y producción.

Requisito 6.4.3

No se utilizan datos de producción (PAN activos) para las pruebas o el desarrollo.

Sus responsabilidades

Asegúrese de que los datos CHD no fluyen al entorno de desarrollo y pruebas. Disponga de documentación clara que proporcione el procedimiento para mover los datos de producción a desarrollo y pruebas. La eliminación de datos reales se debe incluir en ese procedimiento y debe ser aprobada por las partes responsables.

Requisito 6.4.4

Eliminación de datos de pruebas y cuentas de los componentes del sistema antes de que el sistema pase a estar activo o entre en producción.

Sus responsabilidades

Quite los datos de configuración predeterminados, los datos de ejemplo y los datos de prueba conocidos del sistema antes de implementar en producción. No use datos de los titulares de las tarjetas con fines de prueba.

Requisito 6.4.5

Los procedimientos de control de cambios para la implementación de actualizaciones de seguridad y las modificaciones de software deben incluir lo siguiente:

• 6.4.5.1 Documentación del impacto.
• 6.4.5.2 Aprobación del cambio documentado por parte de las entidades autorizadas.
• 6.4.5.3 Prueba de funcionalidades para comprobar que el cambio no afecta negativamente a la seguridad del sistema.
• 6.4.5.4 Procedimientos de retroceso.

Sus responsabilidades

Estos puntos de orientación se correlacionan con los requisitos anteriores:

• Documente los cambios de infraestructura que se esperan como resultado de las actualizaciones de seguridad y las modificaciones de software. Ese proceso es más fácil con el enfoque de infraestructura como código (IaC). Por ejemplo, con un archivo de Bicep o una plantilla de Azure Resource Manager (plantilla de ARM), puede obtener una vista previa de los cambios de la implementación con una operación hipotética. Para obtener más información, consulte Operación hipotética de implementación de Bicep para los cambios de infraestructura.

• Implemente puertas en las canalizaciones de implementación que validen la aprobación de los cambios para las implementaciones periódicas. Documente la justificación de las implementaciones de emergencia en las que es posible que se hayan omitido las puertas.

  Defina los niveles y la profundidad de los cambios. Asegúrese de que el equipo está de acuerdo sobre la definición de cambios significativos frente a cambios menores. Si es práctico, automatice la detección de algunos de esos cambios. Los revisores de la carga de trabajo, la infraestructura y la canalización deben tener un conocimiento claro de los niveles y validar según esos criterios.

• Pruebe la asequibilidad de la seguridad. Asegúrese de que transacciones sintéticas prueban los problemas de seguridad (tanto permitir como denegar). Asegúrese también de que esas pruebas sintéticas se ejecutan en entornos de preproducción.

• Disponga de un proceso de retroceso para el caso de que una corrección de seguridad genere resultados inesperados. Una estrategia común es implementar manteniendo el estado anterior mediante implementaciones azul-verde. En el caso de las cargas de trabajo, incluidas las bases de datos, tenga una estrategia que funcione para la topología específica y esté en el ámbito de las unidades de implementación.

Requisito 6.5

Resuelva las vulnerabilidades de codificación comunes en los procesos de desarrollo de software como se muestra a continuación:

• Formar a los desarrolladores al menos anualmente en técnicas de codificación segura actualizadas, incluida la forma de evitar vulnerabilidades de codificación comunes.
• Desarrollar aplicaciones basadas en instrucciones de codificación segura.

Sus responsabilidades

Es fundamental que los equipos de aplicaciones y los equipos de operaciones estén formados e informados y que se les incentive para respaldar las actividades de análisis de la carga de trabajo y la infraestructura. Estos son algunos recursos:

• Instrucciones de codificación segura
• Protección de DevOps
• Recursos del ciclo de vida de desarrollo seguro

Requisito 6.6

En el caso de las aplicaciones web orientadas al público, solucione las nuevas amenazas y vulnerabilidades de forma continuada. Asegúrese de que estas aplicaciones estén protegidas contra ataques conocidos mediante cualquiera de los métodos siguientes:

• Revise las aplicaciones web orientadas al público mediante herramientas o métodos manuales o automatizados de evaluación de seguridad de las vulnerabilidades de las aplicaciones. Realice una evaluación de vulnerabilidades al menos anualmente y después de cualquier cambio.

  Nota

  Esta evaluación no es igual a los exámenes de vulnerabilidades llevados a cabo para el requisito 11.2.

• Instale una solución automatizada que detecte e impida los ataques basados en web. Por ejemplo, un firewall de aplicaciones web. Impleméntelo delante de las aplicaciones web orientadas al público y evalúe activamente todo el tráfico.

Sus responsabilidades

Disponga de comprobaciones para detectar el tráfico procedente de la red pública de Internet mediante un firewall de aplicaciones web (WAF). En esta arquitectura, Azure Application Gateway comprueba todo el tráfico entrante mediante su WAF integrado. El WAF se basa en Core Rule Set (CRS) de Open Web Application Security Project (OWASP). Si los controles técnicos no están en funcionamiento, disponga de controles de compensación. Una manera es mediante la inspección manual del código.

Asegúrese de que usa las versiones más recientes del conjunto de reglas y aplique las reglas pertinentes para la carga de trabajo. Las reglas deben ejecutarse en modo de prevención. Puede aplicar ese requisito agregando una instancia de Azure Policy que compruebe si el WAF está habilitado y funciona en ese modo.

Mantenga los registros generados por el WAF de Application Gateway para obtener detalles sobre las amenazas detectadas. Ajuste las reglas según sea necesario.

Realice pruebas de penetración centradas en el código de la aplicación. De este modo, los profesionales que no forman parte del equipo de la aplicación encontrarán brechas de seguridad (como la inserción de SQL y el salto de directorio) mediante la recopilación de información, el análisis de vulnerabilidades y la generación de informes. En este ejercicio, es posible que los profesionales necesiten acceder a datos confidenciales. Para asegurarse de que la intención no se use incorrectamente, siga las instrucciones que se proporcionan en Reglas de interacción de las pruebas de penetración.

Requisito 6.7

Asegúrese de que las directivas de seguridad y los procedimientos operativos para desarrollar y mantener protegidas las aplicaciones y los sistemas estén documentados, en uso y que todas las partes afectadas los conozcan.

Sus responsabilidades

Es fundamental mantener una documentación exhaustiva sobre los procesos y las directivas. Los equipos deben estar entrenados para priorizar las opciones de seguridad como parte del ciclo de vida de la carga de trabajo y las operaciones.

El SDL de Microsoft proporciona procedimientos recomendados, herramientas y procesos de seguridad a lo largo de las fases del proceso de desarrollo. Las prácticas de SDL de Microsoft se siguen de manera estricta al crear software en Microsoft. También se sigue el marco de Operational Security Assurance (OSA) para los servicios que operan en la nube. Estas prácticas se publican para ayudarle a proteger las aplicaciones.

• SDL de Microsoft
• OSA de Microsoft

Conserve documentación exhaustiva para las pruebas de penetración que describa el ámbito de la prueba, los procesos de evaluación de prioridades y la estrategia de corrección de los problemas detectados. Si se produce un incidente, incorpore la evaluación del requisito 6 como parte del análisis de la causa principal. Si se detectan brechas (por ejemplo, la infracción de un regla de OWASP), cierre esas brechas.

En la documentación, ofrezca instrucciones claras sobre el estado de protección esperado del WAF.

Las personas que operan en entornos regulados deben estar formadas e informadas y se les debe incentivar para respaldar las garantías de seguridad. Es importante para las personas que forman parte del proceso de aprobación desde la perspectiva de las directivas.

Pasos siguientes

Restricción del acceso a los datos de los titulares de las tarjetas según la información que necesiten las empresas. Identificación y autenticación del acceso a componentes del sistema. Restricción del acceso físico a los datos de los titulares de las tarjetas.