{ "fuente": "PCI DSS v4.0.1 (junio 2024), PCI Security Standards Council – versión en inglés y traducción oficial al español latinoamericano", "marco": "pci-dss", "version": "4.0.1", "version_catalogo": "2026.10.26", "fecha_generacion": "2026-10-26", "idiomas": [ "es", "en" ], "alcance": "Requisitos de PCI DSS v4.0.1 aplicables a la infraestructura en la nube (AWS, Azure, GCP) de entidades que almacenan, procesan o transmiten datos de cuenta, incluidos los requisitos adicionales para proveedores de servicios y el Anexo A1 (proveedores multiusuario).", "nota": "descripcion_larga y remediacion son redacción propia de Nubics/Kyber: parafrasean el requisito sin reproducir el texto del PCI SSC, que tiene derechos reservados. El texto oficial debe consultarse en la biblioteca de documentos del PCI SSC (referencia_documento indica la página). Desde el 31 de marzo de 2025 todos los requisitos con nuevo_en_v4 = true son obligatorios.", "url_oficial": "https://www.pcisecuritystandards.org/document_library/", "licencia_texto_oficial": "licensed_ref_only", "total_controles": 214, "resumen": { "por_tipo": { "documental": 60, "escaneable_directo": 92, "deteccion_presencia": 16, "evidencia_generada": 20, "fuera_alcance_agentless": 4, "retencion_medible": 3, "servicio": 10, "heredado_proveedor": 9 }, "por_severidad": { "info": 21, "high": 118, "low": 52, "crit": 23 }, "por_requisito": { "1": 18, "2": 9, "3": 29, "4": 5, "5": 12, "6": 19, "7": 12, "8": 29, "9": 11, "10": 27, "11": 19, "12": 17, "A1": 7 }, "automatizables": 131, "solo_proveedores_de_servicio": 20, "nuevos_en_v4": 53, "con_mapeo_ucf": 23 }, "requisitos": { "1": { "titulo": "Instalar y mantener los controles de seguridad de la red", "titulo_en": "Install and Maintain Network Security Controls" }, "2": { "titulo": "Aplicar configuraciones seguras a todos los componentes del sistema", "titulo_en": "Apply Secure Configurations to All System Components" }, "3": { "titulo": "Proteger los datos de cuenta almacenados", "titulo_en": "Protect Stored Account Data" }, "4": { "titulo": "Proteger los datos de tarjetahabiente con criptografía robusta durante la transmisión por redes públicas abiertas", "titulo_en": "Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks" }, "5": { "titulo": "Proteger todos los sistemas y redes contra software malicioso", "titulo_en": "Protect All Systems and Networks from Malicious Software" }, "6": { "titulo": "Desarrollar y mantener sistemas y software seguros", "titulo_en": "Develop and Maintain Secure Systems and Software" }, "7": { "titulo": "Restringir el acceso a los componentes del sistema y a los datos de tarjetahabiente según la necesidad de conocer del negocio", "titulo_en": "Restrict Access to System Components and Cardholder Data by Business Need to Know" }, "8": { "titulo": "Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "titulo_en": "Identify Users and Authenticate Access to System Components" }, "9": { "titulo": "Restringir el acceso físico a los datos de tarjetahabiente", "titulo_en": "Restrict Physical Access to Cardholder Data" }, "10": { "titulo": "Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "titulo_en": "Log and Monitor All Access to System Components and Cardholder Data" }, "11": { "titulo": "Probar regularmente la seguridad de los sistemas y las redes", "titulo_en": "Test Security of Systems and Networks Regularly" }, "12": { "titulo": "Respaldar la seguridad de la información con políticas y programas organizacionales", "titulo_en": "Support Information Security with Organizational Policies and Programs" }, "A1": { "titulo": "Anexo A1: requisitos adicionales para proveedores de servicios multiusuario", "titulo_en": "Appendix A1: Additional PCI DSS Requirements for Multi-Tenant Service Providers" } }, "leyenda_kyber_cobertura": { "escaneable_directo": "Verificable con escaneo agentless in-account (APIs de configuración AWS/Azure/GCP y snapshots de discos).", "deteccion_presencia": "Se verifica que la herramienta exista y esté activa, no su eficacia.", "retencion_medible": "Se mide la configuración de retención de bitácoras contra el plazo del requisito.", "evidencia_generada": "Kyber produce el entregable que pide el requisito (inventario, diagrama, listados).", "documental": "Política o proceso; se cubre con el generador de políticas y evidencia cargada por el cliente.", "servicio": "Requiere un servicio humano (pentest, escaneo ASV, revisión de código).", "heredado_proveedor": "En nube lo cubre el proveedor; se referencian sus reportes (AWS Artifact, Microsoft Service Trust Portal, Google Compliance Reports Manager).", "fuera_alcance_agentless": "Vive en endpoints, on-prem o navegador; no cubrible con escaneo de nube." }, "leyenda_kyber_cobertura_en": { "escaneable_directo": "Verifiable through agentless in-account scanning (AWS/Azure/GCP configuration APIs and disk snapshots).", "deteccion_presencia": "Verifies the tool exists and is active, not its effectiveness.", "retencion_medible": "Log retention configuration is measured against the required period.", "evidencia_generada": "Kyber produces the deliverable the requirement asks for (inventory, diagram, listings).", "documental": "Policy or process; covered by the policy generator and customer-uploaded evidence.", "servicio": "Requires a human service (penetration test, ASV scan, code review).", "heredado_proveedor": "Covered by the cloud provider; reference its reports (AWS Artifact, Microsoft Service Trust Portal, Google Compliance Reports Manager).", "fuera_alcance_agentless": "Lives on endpoints, on-prem or in the browser; not coverable by cloud scanning." }, "leyenda_severidad": { "crit": "Exposición directa de datos de cuenta o acceso no autorizado inmediato al CDE.", "high": "Control técnico preventivo o detectivo central.", "low": "Control de soporte o de proceso.", "info": "Requisito documental o de gobierno sin impacto técnico directo." }, "notas_mapeo": [ "Mapeo N:M orientativo elaborado para el UCF de Kyber; no es un crosswalk oficial del PCI SSC, ISO, AICPA, CIS ni Banxico.", "Versiones: ISO/IEC 27001:2022 Anexo A (sin prefijo 'A.'), SOC 2 Trust Services Criteria 2017 (puntos de enfoque revisados 2022), CIS Controls v8.", "kyber_cobertura.capacidades_pendientes lista capacidades del escáner que el check supone y que Kyber aún no implementa (p. ej. deteccion_pan_en_snapshots); esos checks no deben evaluarse hasta que existan.", "banxico_spei se deriva del mapeo pci_dss_v4 del catálogo spei_controles_seguridad_infraestructura.json.", "Los IDs entre corchetes en checks_aws corresponden a controles de AWS Security Hub; los checks aplican solo a recursos marcados por el cliente como parte del CDE o conectados a él.", "mapeo_ucf es la correspondencia curada con la lista unificada de Kyber; cuando un control la trae, la API no deriva mapeos desde mapeo_frameworks." ], "excluidos_por_no_aplicar_a_nube": [ { "numero_regla": "1.3.3", "motivo": "Redes inalámbricas: no existen en infraestructura de nube pública." }, { "numero_regla": "2.3.1, 2.3.2", "motivo": "Entornos inalámbricos: no aplican a nube pública." }, { "numero_regla": "4.2.1.2", "motivo": "Redes inalámbricas que transmiten PAN: no aplican a nube pública." }, { "numero_regla": "5.4.1", "motivo": "Anti-phishing para usuarios finales (correo y personas), fuera de la infraestructura de nube." }, { "numero_regla": "9.1.2, 9.2.4, 9.3.2-9.3.4, 9.4.2-9.4.5, 9.5.x", "motivo": "Controles físicos de oficinas, visitantes, medios en papel y dispositivos POI; los centros de datos de nube se cubren vía 9.2.x/9.3.1/9.4.x heredados." }, { "numero_regla": "11.2.1, 11.2.2", "motivo": "Detección de puntos de acceso inalámbrico no autorizados: no aplica a nube pública." }, { "numero_regla": "12.1.x, 12.2.1, 12.3.2, 12.4.x, 12.6.x, 12.7.1, 12.10.2-12.10.4.1, 12.10.6", "motivo": "Gobierno corporativo, concientización y RR. HH.; se cubren con el programa de políticas, no con la infraestructura de nube." }, { "numero_regla": "A2.x", "motivo": "SSL/TLS temprano en terminales POI presenciales." }, { "numero_regla": "A3.x", "motivo": "Validación suplementaria para entidades designadas (DESV); solo aplica si la marca o el adquirente lo exige." } ], "controles": [ { "id": 1, "numero_regla": "1.1.1", "requisito": "1", "seccion": "1.1", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Procesos y mecanismos de los controles de seguridad de la red definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for network security controls are defined and understood", "descripcion_corta": "Políticas y procedimientos operativos del Requisito 1 documentados, vigentes, en uso y conocidos", "descripcion_larga": "La entidad debe contar con políticas de seguridad y procedimientos operativos que cubran todas las actividades del Requisito 1 (controles de seguridad de la red, NSC). Estos documentos deben estar por escrito, actualizarse cuando cambien procesos, tecnologías u objetivos de negocio (no solo en un ciclo periódico), aplicarse realmente en la operación y ser conocidos por todo el personal involucrado. El objetivo es que las actividades de seguridad de red sean repetibles, consistentes y alineadas con la intención de la dirección.", "remediacion": "1. Redactar una política de seguridad de red y procedimientos operativos que cubran estándares de reglas de NSC (security groups, NACL, Azure NSG/Azure Firewall, reglas de firewall de VPC de GCP, WAF), control de cambios, diagramas, revisiones semestrales y segmentación del CDE. 2. Asignar un dueño del documento, versionarlo (control de versiones con fecha y aprobador) y revisarlo al menos una vez al año y después de cada cambio relevante en la arquitectura de nube. 3. Publicarlo en un repositorio accesible y recabar acuse de lectura del personal de redes, nube y DevOps. 4. Vincular los procedimientos con la operación real (runbooks, pipelines de IaC, plantillas de tickets). 5. Conservar como evidencia para el QSA: la política aprobada, el historial de versiones, los acuses de lectura y ejemplos de registros que muestren que los procedimientos se siguen.", "descripcion_corta_en": "Requirement 1 security policies and operational procedures documented, current, in use and known", "descripcion_larga_en": "The entity must have security policies and operational procedures covering every activity in Requirement 1 (network security controls, NSCs). These documents must be written down, updated whenever processes, technologies or business objectives change (not only on a periodic cycle), actually followed in operations, and known to all affected personnel. The goal is for network security activities to be repeatable, consistent and aligned with management intent.", "remediacion_en": "1. Write a network security policy and operational procedures covering NSC ruleset standards (security groups, NACLs, Azure NSG/Azure Firewall, GCP VPC firewall rules, WAF), change control, diagrams, six-monthly reviews and CDE segmentation. 2. Assign a document owner, version it (change history with date and approver) and review it at least annually and after every significant cloud architecture change. 3. Publish it in an accessible repository and collect read acknowledgments from network, cloud and DevOps staff. 4. Tie procedures to real operations (runbooks, IaC pipelines, ticket templates). 5. Keep as QSA evidence: the approved policy, version history, acknowledgments and sample records showing procedures are followed.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 44, "pagina_pdf_es": 49 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Política de seguridad de red y procedimientos aprobados, con historial de versiones, evidencia de difusión (acuses de lectura) y registros que demuestren su uso. Kyber puede generar la plantilla de política a partir del generador de políticas.", "evidencia_en": "Approved network security policy and procedures with version history, proof of dissemination (read acknowledgments) and records demonstrating use. Kyber can produce a policy template through its policy generator.", "limitaciones": "El escaneo no puede verificar que las políticas estén vigentes, en uso ni que el personal las conozca; requiere revisión documental y entrevistas.", "limitaciones_en": "Scanning cannot verify that policies are current, in use or known to staff; this requires document review and interviews.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.1", "5.37" ], "soc2_tsc": [ "CC5.3", "CC2.2" ], "cis_controls_v8": [ "4.2" ] } }, { "id": 2, "numero_regla": "1.1.2", "requisito": "1", "seccion": "1.1", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Procesos y mecanismos de los controles de seguridad de la red definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for network security controls are defined and understood", "descripcion_corta": "Roles y responsabilidades del Requisito 1 documentados, asignados y comprendidos", "descripcion_larga": "Las funciones y responsabilidades para ejecutar las actividades del Requisito 1 deben estar documentadas, asignadas formalmente a personas y ser entendidas por ellas. Esto puede hacerse dentro de las políticas o en documentos separados, por ejemplo con una matriz RACI. El fin es que las tareas cotidianas de seguridad de red no queden sin responsable y que el personal rinda cuentas por su operación continua.", "remediacion": "1. Elaborar una matriz RACI para las actividades del Requisito 1: diseño y aprobación de reglas de NSC, control de cambios, mantenimiento de diagramas de red y de flujo de datos, revisión semestral de reglas y gestión de cuentas/proyectos/suscripciones de nube. 2. Asignar nombres o puestos concretos (p. ej. equipo de plataforma de nube, seguridad, redes) y suplentes. 3. Incluir las responsabilidades en descripciones de puesto o en la política de red. 4. Obtener acuse de aceptación de cada responsable y revisar la matriz cuando cambie la organización. 5. Evidencia para el QSA: matriz RACI aprobada, acuses firmados y entrevistas al personal que confirmen que conoce su rol.", "descripcion_corta_en": "Requirement 1 roles and responsibilities documented, assigned and understood", "descripcion_larga_en": "Roles and responsibilities for carrying out Requirement 1 activities must be documented, formally assigned to people, and understood by them. This can be done inside policies or in separate documents, for example a RACI matrix. The aim is that day-to-day network security tasks always have an owner and that personnel are accountable for their continuous operation.", "remediacion_en": "1. Build a RACI matrix for Requirement 1 activities: NSC rule design and approval, change control, network and data-flow diagram maintenance, six-monthly rule reviews and cloud account/project/subscription management. 2. Assign specific names or positions (e.g., cloud platform, security, networking teams) and backups. 3. Include the responsibilities in job descriptions or in the network policy. 4. Obtain acceptance acknowledgments from each owner and update the matrix when the organization changes. 5. QSA evidence: approved RACI matrix, signed acknowledgments and staff interviews confirming they understand their role.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 45, "pagina_pdf_es": 50 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Matriz RACI o documento de roles aprobado, acuses de aceptación de responsabilidades y registros de entrevistas.", "evidencia_en": "Approved RACI matrix or roles document, responsibility acceptance acknowledgments and interview records.", "limitaciones": "No es verificable por escaneo; depende de documentación y entrevistas al personal.", "limitaciones_en": "Not verifiable through scanning; relies on documentation and staff interviews.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.2", "5.3" ], "soc2_tsc": [ "CC1.3", "CC1.4" ], "cis_controls_v8": [] } }, { "id": 3, "numero_regla": "1.2.1", "requisito": "1", "seccion": "1.2", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Configuración y mantenimiento de los controles de seguridad de la red (NSC)", "seccion_titulo_en": "Network security controls (NSCs) are configured and maintained", "descripcion_corta": "Estándares de configuración de reglas de NSC definidos, implementados y mantenidos", "descripcion_larga": "La entidad debe definir estándares de configuración para los conjuntos de reglas de sus controles de seguridad de la red (NSC), implementarlos en los NSC reales y mantenerlos actualizados. Estos estándares suelen establecer protocolos y puertos permitidos, requisitos de configuración aceptables y lo que no está permitido en la red. En nube, los NSC incluyen redes virtuales, security groups, listas de control de acceso, firewalls administrados y WAF.", "remediacion": "1. Documentar un estándar de reglas de NSC por tipo de control: security groups y NACL (AWS), NSG y Azure Firewall (Azure), reglas de firewall de VPC y políticas jerárquicas (GCP), WAF/Cloud Armor; incluir denegación por defecto, puertos permitidos por capa (web, aplicación, base de datos), prohibición de 0.0.0.0/0 y ::/0 hacia el CDE salvo componentes públicos aprobados y uso obligatorio de etiquetas de propietario/justificación. 2. Implementar el estándar como código (Terraform/CloudFormation/Bicep) y como guardas preventivas: AWS Firewall Manager y SCP, Azure Policy (deny), GCP Organization Policy y políticas jerárquicas de firewall. 3. Restringir el security group predeterminado de cada VPC para que no permita tráfico. 4. Evaluar continuamente las reglas reales contra el estándar con AWS Config/Security Hub, Microsoft Defender for Cloud y Security Command Center. 5. Revisar el estándar al menos anualmente. Evidencia: estándar aprobado, código de IaC y reporte de cumplimiento de las reglas contra el estándar.", "descripcion_corta_en": "NSC ruleset configuration standards defined, implemented and maintained", "descripcion_larga_en": "The entity must define configuration standards for the rulesets of its network security controls (NSCs), implement them on the actual NSCs and keep them up to date. These standards typically set the allowed protocols and ports, acceptable configuration requirements and what is not permitted on the network. In the cloud, NSCs include virtual networks, security groups, access control lists, managed firewalls and WAFs.", "remediacion_en": "1. Document an NSC ruleset standard per control type: security groups and NACLs (AWS), NSGs and Azure Firewall (Azure), VPC firewall rules and hierarchical policies (GCP), WAF/Cloud Armor; include default deny, allowed ports per tier (web, app, database), a ban on 0.0.0.0/0 and ::/0 toward the CDE except for approved public components, and mandatory owner/justification tags. 2. Implement the standard as code (Terraform/CloudFormation/Bicep) and as preventive guardrails: AWS Firewall Manager and SCPs, Azure Policy (deny), GCP Organization Policy and hierarchical firewall policies. 3. Restrict each VPC's default security group so it allows no traffic. 4. Continuously evaluate live rules against the standard with AWS Config/Security Hub, Microsoft Defender for Cloud and Security Command Center. 5. Review the standard at least annually. Evidence: approved standard, IaC code and a compliance report of live rules against the standard.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 46, "pagina_pdf_es": 51 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Security group predeterminado de cada VPC sin reglas de entrada ni salida (falla si tiene reglas) [EC2.2]", "Security groups sin etiquetas de propietario/justificación definidas en el estándar (falla si faltan)", "Security groups o NACL que permiten 0.0.0.0/0 o ::/0 hacia recursos etiquetados como CDE (falla si existe)", "AWS Firewall Manager o AWS Config habilitado para evaluar políticas de security groups en todas las cuentas de la organización" ], "checks_azure": [ "Subredes y NIC sin NSG asociado (falla si no hay NSG)", "Reglas de NSG con origen Any/Internet/* hacia subredes etiquetadas como CDE (falla si existe)", "Asignaciones de Azure Policy para restringir reglas de NSG en las suscripciones del CDE (falla si no existen)" ], "checks_gcp": [ "Red 'default' presente en proyectos del CDE (falla si existe)", "Reglas de firewall de VPC con sourceRanges 0.0.0.0/0 hacia instancias o etiquetas de red del CDE (falla si existe)", "Políticas jerárquicas de firewall a nivel organización o carpeta configuradas (falla si no existen)" ], "evidencia": "Kyber genera el inventario de reglas de todos los NSC y su evaluación contra el estándar; el cliente aporta el estándar de configuración aprobado.", "evidencia_en": "Kyber produces an inventory of all NSC rules and their evaluation against the standard; the customer provides the approved configuration standard.", "limitaciones": "El escaneo verifica la configuración aplicada, pero no puede confirmar que el estándar documentado exista, esté aprobado o se mantenga; NSC fuera de la nube (on-prem, appliances virtuales de terceros) requieren evidencia aparte.", "limitaciones_en": "Scanning verifies the applied configuration but cannot confirm that the documented standard exists, is approved or is maintained; non-cloud NSCs (on-prem, third-party virtual appliances) need separate evidence.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.20", "8.9" ], "soc2_tsc": [ "CC6.6", "CC6.1" ], "cis_controls_v8": [ "4.2", "12.2" ], "banxico_spei": [ "58a. I.A.f).2", "58a. I.A.f).3" ] }, "mapeo_ucf": [ { "clave": "UCF-NET-001", "relacion": "equivalent", "cobertura_pct": 80 }, { "clave": "UCF-NET-002", "relacion": "partial", "cobertura_pct": 30 } ] }, { "id": 4, "numero_regla": "1.2.2", "requisito": "1", "seccion": "1.2", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Configuración y mantenimiento de los controles de seguridad de la red (NSC)", "seccion_titulo_en": "Network security controls (NSCs) are configured and maintained", "descripcion_corta": "Cambios a conexiones de red y a configuraciones de NSC aprobados vía control de cambios (6.5.1)", "descripcion_larga": "Todo cambio a las conexiones de red y a la configuración de los NSC debe aprobarse y gestionarse mediante el proceso formal de control de cambios definido en el requisito 6.5.1. Los cambios a conexiones abarcan agregar, quitar o modificar una conexión; los cambios a NSC incluyen tanto los del componente en sí como los que alteran su función de seguridad. El propósito es que ningún cambio introduzca configuraciones erróneas, servicios inseguros o conexiones no autorizadas.", "remediacion": "1. Incluir explícitamente en el procedimiento de cambios (6.5.1) los cambios a security groups, NACL, tablas de rutas, VPC peering, Transit Gateway, VPN, Direct Connect/ExpressRoute/Interconnect, NSG, Azure Firewall, reglas de firewall de VPC y WAF. 2. Gestionar la red como código: todo cambio pasa por pull request con revisión y aprobación, y se despliega solo desde el pipeline; bloquear cambios manuales en producción con SCP/IAM, Azure RBAC y resource locks, o permisos de GCP restringidos. 3. Registrar todos los cambios con CloudTrail, Azure Activity Log y Cloud Audit Logs, y configurar alertas para cambios a security groups, NACL, gateways y rutas. 4. Conciliar periódicamente los cambios registrados contra los tickets aprobados y documentar la verificación posterior. 5. Evidencia: procedimiento de cambios, muestras de tickets aprobados vinculados a commits/PR y registros de auditoría de los cambios.", "descripcion_corta_en": "Changes to network connections and NSC configurations approved via change control (6.5.1)", "descripcion_larga_en": "Every change to network connections and to NSC configurations must be approved and managed through the formal change control process defined in Requirement 6.5.1. Connection changes cover adding, removing or modifying a connection; NSC changes include those to the component itself and those that alter how it performs its security function. The purpose is to prevent changes from introducing misconfigurations, insecure services or unauthorized connections.", "remediacion_en": "1. Explicitly include in the change procedure (6.5.1) changes to security groups, NACLs, route tables, VPC peering, Transit Gateway, VPN, Direct Connect/ExpressRoute/Interconnect, NSGs, Azure Firewall, VPC firewall rules and WAF. 2. Manage the network as code: every change goes through a reviewed and approved pull request and is deployed only from the pipeline; block manual production changes with SCPs/IAM, Azure RBAC and resource locks, or restricted GCP permissions. 3. Record all changes with CloudTrail, Azure Activity Log and Cloud Audit Logs, and alert on changes to security groups, NACLs, gateways and routes. 4. Periodically reconcile recorded changes against approved tickets and document post-change verification. 5. Evidence: change procedure, sample approved tickets linked to commits/PRs, and audit logs of the changes.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 47, "pagina_pdf_es": 52 }, "kyber_cobertura": { "tipo": "deteccion_presencia", "automatizacion": "media", "checks_aws": [ "CloudTrail multi-región habilitado [CloudTrail.1]", "Filtros de métricas y alarmas de CloudWatch para cambios en security groups, NACL, gateways de red y tablas de rutas (falla si no existen)", "AWS Config recorder habilitado y registrando AWS::EC2::SecurityGroup, NetworkAcl, RouteTable y VPC [Config.1]" ], "checks_azure": [ "Alertas del Activity Log para creación/actualización/eliminación de NSG y reglas de NSG (falla si no existen)", "Diagnostic settings exportando el Activity Log de todas las suscripciones del CDE", "Resource locks o Azure Policy que impidan cambios de red fuera del pipeline en suscripciones del CDE" ], "checks_gcp": [ "Métricas basadas en logs y alertas para cambios en reglas de firewall de VPC, rutas y redes VPC (falla si no existen)", "Cloud Audit Logs de actividad de administración exportados mediante sink a nivel organización" ], "evidencia": "Kyber reporta la presencia de registro y alertas de cambios de red y lista los cambios detectados en el periodo; el cliente aporta el procedimiento de control de cambios y los tickets aprobados que los respaldan.", "evidencia_en": "Kyber reports the presence of network change logging and alerting and lists changes detected in the period; the customer provides the change control procedure and approved tickets supporting them.", "limitaciones": "El escaneo detecta que existan registro y alertas de cambios, pero no puede confirmar que cada cambio haya sido aprobado, probado y documentado conforme a 6.5.1.", "limitaciones_en": "Scanning detects that change logging and alerting exist but cannot confirm that each change was approved, tested and documented per 6.5.1.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.32", "8.9" ], "soc2_tsc": [ "CC8.1" ], "cis_controls_v8": [ "4.2" ] } }, { "id": 5, "numero_regla": "1.2.3", "requisito": "1", "seccion": "1.2", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Configuración y mantenimiento de los controles de seguridad de la red (NSC)", "seccion_titulo_en": "Network security controls (NSCs) are configured and maintained", "descripcion_corta": "Diagrama de red preciso con todas las conexiones entre el CDE y otras redes", "descripcion_larga": "Debe mantenerse uno o varios diagramas de red exactos que muestren todas las conexiones entre el entorno de datos del titular de la tarjeta (CDE) y cualquier otra red, incluidas las inalámbricas. El diagrama debe actualizarse cuando cambie el entorno y representar las fronteras entre el CDE, las redes confiables y las no confiables. Puede usarse un diagrama vigente u otra solución técnica o topológica que identifique conexiones y dispositivos de red.", "remediacion": "1. Generar el diagrama a partir del inventario real de la nube: VPC/VNet, subredes, tablas de rutas, Internet/NAT gateways, VPC peering, Transit Gateway/Virtual WAN/Network Connectivity Center, VPN, Direct Connect/ExpressRoute/Interconnect, balanceadores, NSC (security groups, NSG, firewalls, WAF) y endpoints privados. 2. Etiquetar claramente los segmentos del CDE, los conectados y los fuera de alcance (p. ej. sombreados), e incluir leyenda, ubicaciones (regiones, oficinas, centros de datos, otros proveedores de nube) y conexiones inalámbricas que lleguen al CDE. 3. Registrar fecha de última actualización, autor y aprobador. 4. Regenerar el diagrama automáticamente tras cada cambio de red y revisarlo al menos cada seis meses junto con la revisión de NSC. 5. Evidencia: diagrama vigente aprobado y su comparación contra la configuración real.", "descripcion_corta_en": "Accurate network diagram showing all connections between the CDE and other networks", "descripcion_larga_en": "One or more accurate network diagrams must be maintained showing every connection between the cardholder data environment (CDE) and any other network, including wireless networks. The diagram must be updated when the environment changes and represent the boundaries between the CDE, trusted networks and untrusted networks. A current diagram or another technical or topological solution that identifies network connections and devices may be used.", "remediacion_en": "1. Generate the diagram from the live cloud inventory: VPCs/VNets, subnets, route tables, Internet/NAT gateways, VPC peering, Transit Gateway/Virtual WAN/Network Connectivity Center, VPNs, Direct Connect/ExpressRoute/Interconnect, load balancers, NSCs (security groups, NSGs, firewalls, WAF) and private endpoints. 2. Clearly label CDE, connected and out-of-scope segments (e.g., shaded), and include a legend, locations (regions, offices, data centers, other cloud providers) and any wireless connections reaching the CDE. 3. Record last update date, author and approver. 4. Regenerate the diagram automatically after every network change and review it at least every six months along with the NSC review. 5. Evidence: current approved diagram and its reconciliation against the live configuration.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 48, "pagina_pdf_es": 53 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Inventario de VPC, subredes, tablas de rutas, IGW/NAT, VPC peering, Transit Gateway, VPN y Direct Connect por cuenta y región", "Recursos sin etiqueta de alcance PCI (CDE/conectado/fuera de alcance) (falla si faltan)", "Rutas hacia Internet Gateway en subredes etiquetadas como CDE (se marcan en el diagrama como frontera no confiable)" ], "checks_azure": [ "Inventario de VNet, subredes, peerings, Virtual WAN, VPN/ExpressRoute gateways, Azure Firewall y NSG por suscripción", "Recursos sin etiqueta de alcance PCI (falla si faltan)" ], "checks_gcp": [ "Inventario de redes VPC, subredes, Shared VPC, VPC peering, Cloud VPN, Cloud Interconnect, Cloud NAT y reglas de firewall por proyecto", "Recursos sin etiqueta (label) de alcance PCI (falla si faltan)" ], "evidencia": "Kyber genera el diagrama de red a partir del inventario de nube con fecha de generación y segmentos etiquetados; el cliente agrega conexiones no visibles en la nube (oficinas, redes inalámbricas, terceros) y registra la aprobación.", "evidencia_en": "Kyber generates the network diagram from the cloud inventory with generation date and labeled segments; the customer adds connections not visible in the cloud (offices, wireless networks, third parties) and records approval.", "limitaciones": "El escaneo solo ve la topología de nube; no conoce redes on-prem, inalámbricas ni de terceros, ni puede decidir por sí mismo qué es CDE sin etiquetas proporcionadas por el cliente.", "limitaciones_en": "Scanning only sees the cloud topology; it does not know on-prem, wireless or third-party networks, nor can it determine what is CDE without customer-provided tags.", "responsabilidad_compartida": "cliente", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.20", "5.9" ], "soc2_tsc": [ "CC6.1", "CC2.1" ], "cis_controls_v8": [ "12.4" ], "banxico_spei": [ "58a. I.A.f).4" ] } }, { "id": 6, "numero_regla": "1.2.4", "requisito": "1", "seccion": "1.2", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Configuración y mantenimiento de los controles de seguridad de la red (NSC)", "seccion_titulo_en": "Network security controls (NSCs) are configured and maintained", "descripcion_corta": "Diagrama de flujo de datos preciso que muestra todos los flujos de datos de cuenta", "descripcion_larga": "Debe mantenerse uno o varios diagramas de flujo de datos exactos que muestren todos los flujos de datos de cuenta a través de sistemas y redes, y que se actualicen cuando cambie el entorno. El diagrama complementa y debe ser coherente con el diagrama de red. Puede usarse otra solución técnica o topológica que identifique los flujos de datos de cuenta entre sistemas y redes.", "remediacion": "1. Identificar todos los puntos donde los datos de cuenta entran y salen del entorno (APIs de pago, pasarelas, adquirentes, TPSP) y trazar su recorrido por servicios de nube: balanceadores, API Gateway/Application Gateway, cómputo, colas, bases de datos, almacenamiento de objetos, respaldos y réplicas entre regiones. 2. Indicar para cada flujo el tipo de procesamiento (autorización, captura, liquidación, contracargos, reembolsos), canal, protocolo y cifrado, y dónde se almacenan los datos y por cuánto tiempo. 3. Validar los flujos contra VPC Flow Logs, NSG/VNet flow logs y VPC Flow Logs de GCP, y contra las etiquetas de los recursos del CDE. 4. Registrar fecha, autor y aprobador; actualizar ante cada cambio que afecte los flujos. 5. Evidencia: diagrama aprobado, conciliado con el diagrama de red (1.2.3).", "descripcion_corta_en": "Accurate data-flow diagram showing all account data flows", "descripcion_larga_en": "One or more accurate data-flow diagrams must be maintained that show all account data flows across systems and networks and are updated when the environment changes. The diagram complements and must be consistent with the network diagram. Another technical or topological solution that identifies account data flows across systems and networks may be used.", "remediacion_en": "1. Identify every point where account data enters and leaves the environment (payment APIs, gateways, acquirers, TPSPs) and trace its path through cloud services: load balancers, API Gateway/Application Gateway, compute, queues, databases, object storage, backups and cross-region replicas. 2. For each flow, state the processing type (authorization, capture, settlement, chargebacks, refunds), channel, protocol and encryption, and where data is stored and for how long. 3. Validate flows against VPC Flow Logs, NSG/VNet flow logs and GCP VPC Flow Logs, and against CDE resource tags. 4. Record date, author and approver; update upon every change affecting flows. 5. Evidence: approved diagram reconciled with the network diagram (1.2.3).", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 49, "pagina_pdf_es": 55 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "VPC Flow Logs habilitados en todas las VPC del CDE [EC2.6]", "Inventario de buckets S3, RDS, DynamoDB y réplicas entre regiones etiquetados como almacenamiento de datos de cuenta", "Recursos que reciben tráfico desde ALB/API Gateway etiquetados como CDE" ], "checks_azure": [ "NSG flow logs o VNet flow logs habilitados con Traffic Analytics en las VNet del CDE", "Inventario de Storage Accounts, Azure SQL y Cosmos DB etiquetados como almacenamiento de datos de cuenta" ], "checks_gcp": [ "VPC Flow Logs habilitados en todas las subredes del CDE", "Inventario de buckets de Cloud Storage, Cloud SQL, BigQuery y Spanner etiquetados como almacenamiento de datos de cuenta" ], "evidencia": "Kyber genera un borrador del diagrama de flujo de datos a partir del inventario etiquetado y de los flow logs; el cliente completa la lógica de negocio (canales, procesamiento, terceros) y registra la aprobación.", "evidencia_en": "Kyber generates a draft data-flow diagram from tagged inventory and flow logs; the customer completes the business logic (channels, processing, third parties) and records approval.", "limitaciones": "El escaneo no ve el contenido del tráfico ni la lógica de la aplicación, por lo que no puede confirmar por sí solo qué flujos transportan datos de cuenta; tampoco cubre flujos en papel ni fuera de la nube.", "limitaciones_en": "Scanning cannot see traffic content or application logic, so it cannot by itself confirm which flows carry account data; it also does not cover paper or non-cloud flows.", "responsabilidad_compartida": "cliente", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.9", "5.14", "8.20" ], "soc2_tsc": [ "CC6.1", "CC2.1" ], "cis_controls_v8": [ "3.8" ], "banxico_spei": [ "58a. I.A.f).4" ] } }, { "id": 7, "numero_regla": "1.2.5", "requisito": "1", "seccion": "1.2", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Configuración y mantenimiento de los controles de seguridad de la red (NSC)", "seccion_titulo_en": "Network security controls (NSCs) are configured and maintained", "descripcion_corta": "Servicios, protocolos y puertos permitidos identificados, aprobados y con necesidad de negocio", "descripcion_larga": "Todos los servicios, protocolos y puertos que los NSC permiten deben estar identificados, aprobados y respaldados por una necesidad de negocio definida. Debe existir una lista con la justificación y aprobación de cada uno, y la configuración de los NSC debe permitir únicamente lo aprobado. Se recomienda que la aprobación la otorgue personal independiente de quien administra la configuración.", "remediacion": "1. Construir un registro de puertos/protocolos permitidos por segmento (p. ej. 443/TCP desde Internet al ALB, 5432/TCP solo desde la subred de aplicación a la base de datos) con justificación, dueño y aprobador independiente. 2. Representar la justificación en etiquetas o descripciones de cada regla (description de reglas de security group, NSG y firewall de VPC). 3. Eliminar reglas con protocolo 'all'/-1, rangos amplios de puertos (p. ej. 0-65535) o destinos no justificados. 4. Comparar automáticamente las reglas reales contra el registro aprobado y alertar sobre desviaciones (AWS Config/Firewall Manager, Azure Policy, GCP Firewall Insights). 5. Evidencia: registro aprobado de servicios/puertos y reporte de reglas reales que coinciden con él.", "descripcion_corta_en": "Allowed services, protocols and ports identified, approved and with a business need", "descripcion_larga_en": "All services, protocols and ports allowed by NSCs must be identified, approved and backed by a defined business need. A list must exist with the justification and approval for each, and NSC configurations must allow only what is approved. Approval is ideally granted by personnel independent of those who manage the configuration.", "remediacion_en": "1. Build a register of allowed ports/protocols per segment (e.g., 443/TCP from the Internet to the ALB, 5432/TCP only from the app subnet to the database) with justification, owner and independent approver. 2. Record the justification in each rule's tags or description (security group, NSG and VPC firewall rule descriptions). 3. Remove rules with protocol 'all'/-1, broad port ranges (e.g., 0-65535) or unjustified destinations. 4. Automatically compare live rules against the approved register and alert on deviations (AWS Config/Firewall Manager, Azure Policy, GCP Firewall Insights). 5. Evidence: approved services/ports register and report of live rules matching it.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 51, "pagina_pdf_es": 57 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Security groups con IpProtocol -1 (todo el tráfico) en reglas de entrada (falla si existe)", "Security groups que permiten entrada sin restricción solo en puertos autorizados (falla si hay 0.0.0.0/0 en puertos distintos a los permitidos) [EC2.18]", "Reglas de security group sin descripción/justificación (falla si falta)", "Reglas con rangos de puertos amplios (más de N puertos) hacia recursos del CDE (falla si existe)" ], "checks_azure": [ "Reglas de NSG con destinationPortRange '*' o protocolo '*' (falla si existe)", "Reglas de NSG sin descripción/justificación (falla si falta)", "Reglas de Azure Firewall con puertos o protocolos no incluidos en la lista aprobada (falla si existe)" ], "checks_gcp": [ "Reglas de firewall de VPC con allowed IPProtocol 'all' (falla si existe)", "Reglas de firewall sin descripción (falla si falta)", "Firewall Insights: reglas permisivas en exceso o sin uso (alerta)" ], "evidencia": "Kyber genera el listado de todos los servicios, protocolos y puertos permitidos por cada NSC y lo compara contra la lista aprobada cargada por el cliente.", "evidencia_en": "Kyber generates the list of all services, protocols and ports allowed by each NSC and compares it with the approved list uploaded by the customer.", "limitaciones": "El escaneo no puede evaluar la validez de la justificación de negocio ni la independencia del aprobador; sin la lista aprobada solo detecta reglas evidentemente excesivas.", "limitaciones_en": "Scanning cannot judge whether the business justification is valid or whether the approver is independent; without the approved list it only detects obviously excessive rules.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.20", "8.21" ], "soc2_tsc": [ "CC6.6" ], "cis_controls_v8": [ "4.8", "13.4" ], "banxico_spei": [ "58a. I.A.f).6", "58a. I.A.g).6" ] } }, { "id": 8, "numero_regla": "1.2.6", "requisito": "1", "seccion": "1.2", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Configuración y mantenimiento de los controles de seguridad de la red (NSC)", "seccion_titulo_en": "Network security controls (NSCs) are configured and maintained", "descripcion_corta": "Medidas de seguridad definidas e implementadas para servicios, protocolos y puertos inseguros en uso", "descripcion_larga": "Para cada servicio, protocolo o puerto en uso que se considere inseguro, la entidad debe definir e implementar características de seguridad que mitiguen su riesgo. Debe existir documentación que identifique cada elemento inseguro y sus mitigaciones, y estas deben estar aplicadas en los NSC. Para determinar qué es inseguro se recomienda consultar guías del sector como NIST, ENISA u OWASP.", "remediacion": "1. Identificar servicios/protocolos inseguros alcanzables a través de los NSC: Telnet (23), FTP (20/21), TFTP (69), SNMP v1/v2c (161/162), HTTP sin cifrar (80) hacia datos sensibles, SMB (445), RDP/SSH expuestos, listeners con TLS 1.0/1.1. 2. Preferir su eliminación; si son indispensables, documentar la justificación, el riesgo aceptado por la dirección y los controles compensatorios. 3. Implementar mitigaciones: restringir origen a IP privadas específicas, encapsular en VPN/TLS, redirigir HTTP a HTTPS en ALB/Application Gateway/HTTPS Load Balancer, aplicar políticas TLS mínimas de 1.2, y exigir acceso administrativo vía AWS Systems Manager Session Manager, Azure Bastion o IAP de GCP. 4. Verificar trimestralmente con el escaneo de configuración. 5. Evidencia: inventario de servicios inseguros con mitigaciones y configuraciones que las demuestren.", "descripcion_corta_en": "Security features defined and implemented for insecure services, protocols and ports in use", "descripcion_larga_en": "For every service, protocol or port in use that is considered insecure, the entity must define and implement security features that mitigate its risk. Documentation must identify each insecure item and its mitigations, and those mitigations must be applied in the NSCs. Industry guidance such as NIST, ENISA or OWASP should be used to determine what is insecure.", "remediacion_en": "1. Identify insecure services/protocols reachable through NSCs: Telnet (23), FTP (20/21), TFTP (69), SNMP v1/v2c (161/162), cleartext HTTP (80) toward sensitive data, SMB (445), exposed RDP/SSH, listeners allowing TLS 1.0/1.1. 2. Prefer removing them; if indispensable, document the justification, management risk acceptance and compensating controls. 3. Implement mitigations: restrict sources to specific private IPs, wrap in VPN/TLS, redirect HTTP to HTTPS on ALB/Application Gateway/HTTPS Load Balancer, enforce TLS 1.2 minimum policies, and require administrative access via AWS Systems Manager Session Manager, Azure Bastion or GCP IAP. 4. Verify quarterly with configuration scanning. 5. Evidence: inventory of insecure services with mitigations and configurations demonstrating them.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 52, "pagina_pdf_es": 58 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Security groups que permiten puertos de alto riesgo (20, 21, 23, 69, 161, 445, 3389, etc.) desde 0.0.0.0/0 (falla si existe) [EC2.19]", "Listeners HTTP de ALB sin redirección a HTTPS (falla si existe) [ELB.1]", "Listeners HTTPS/TLS de ELB con políticas que permiten TLS 1.0/1.1 (falla si existe)", "AWS Transfer Family con protocolo FTP habilitado (falla si existe)" ], "checks_azure": [ "Reglas de NSG que permiten 21, 23, 69, 161 o 445 desde Internet (falla si existe)", "Application Gateway/Front Door con listeners HTTP sin redirección a HTTPS o con TLS mínimo menor a 1.2 (falla si existe)", "App Service con ftpsState = AllAllowed (falla si existe)" ], "checks_gcp": [ "Reglas de firewall de VPC que permiten 21, 23, 69, 161 o 445 desde 0.0.0.0/0 (falla si existe)", "Políticas SSL de balanceadores con minTlsVersion menor a TLS_1_2 (falla si existe)", "Target HTTP proxies sin redirección a HTTPS en balanceadores públicos (falla si existe)" ], "evidencia": "Kyber lista los servicios, protocolos y puertos inseguros detectados en los NSC y su exposición; el cliente aporta la justificación, aceptación de riesgo y las mitigaciones documentadas.", "evidencia_en": "Kyber lists insecure services, protocols and ports detected in NSCs and their exposure; the customer provides the justification, risk acceptance and documented mitigations.", "limitaciones": "El escaneo no evalúa la eficacia de mitigaciones fuera de la nube (p. ej. VPN de terceros) ni confirma que la aceptación de riesgo esté documentada.", "limitaciones_en": "Scanning does not assess the effectiveness of mitigations outside the cloud (e.g., third-party VPNs) nor confirm that risk acceptance is documented.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.20", "8.21" ], "soc2_tsc": [ "CC6.6", "CC6.7" ], "cis_controls_v8": [ "4.8", "3.10" ] } }, { "id": 9, "numero_regla": "1.2.7", "requisito": "1", "seccion": "1.2", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Configuración y mantenimiento de los controles de seguridad de la red (NSC)", "seccion_titulo_en": "Network security controls (NSCs) are configured and maintained", "descripcion_corta": "Revisión de configuraciones de NSC al menos cada seis meses", "descripcion_larga": "Las configuraciones de los NSC deben revisarse como mínimo cada seis meses para confirmar que siguen siendo pertinentes y eficaces. Deben existir procedimientos definidos para esta revisión, evidencia de que se realiza y de que las reglas que ya no tienen justificación de negocio se eliminan o actualizan. La revisión puede ser manual, automatizada o basada en sistemas; con alto volumen de cambios conviene hacerla con mayor frecuencia.", "remediacion": "1. Definir un procedimiento semestral (o más frecuente) de revisión de reglas de security groups, NACL, AWS Network Firewall/WAF, NSG, Azure Firewall, reglas de firewall de VPC y Cloud Armor, con responsables y plantilla de resultados. 2. Generar en cada ciclo un reporte de todas las reglas con su justificación, fecha de creación, uso real (VPC Flow Logs, NSG flow logs, Firewall Insights) y desviaciones contra el estándar. 3. Eliminar o ajustar reglas sin uso, sin justificación vigente o redundantes, y security groups huérfanos. 4. Escalar discrepancias y registrar la aprobación del resultado. 5. Evidencia: procedimiento, reportes fechados de las dos últimas revisiones (intervalo ≤ 6 meses) y tickets de las reglas removidas.", "descripcion_corta_en": "NSC configurations reviewed at least every six months", "descripcion_larga_en": "NSC configurations must be reviewed at least once every six months to confirm they remain relevant and effective. Procedures for this review must be defined, there must be evidence that it occurs, and rules no longer supported by a business justification must be removed or updated. The review may be manual, automated or system-based; organizations with a high volume of changes should review more often.", "remediacion_en": "1. Define a six-monthly (or more frequent) review procedure for security group, NACL, AWS Network Firewall/WAF, NSG, Azure Firewall, VPC firewall and Cloud Armor rules, with owners and a results template. 2. In each cycle, generate a report of all rules with justification, creation date, actual usage (VPC Flow Logs, NSG flow logs, Firewall Insights) and deviations from the standard. 3. Remove or adjust unused, no-longer-justified or redundant rules, and orphaned security groups. 4. Escalate discrepancies and record approval of the outcome. 5. Evidence: procedure, dated reports from the last two reviews (interval ≤ 6 months) and tickets for removed rules.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 53, "pagina_pdf_es": 59 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Security groups no asociados a ninguna interfaz de red (huérfanos) (alerta)", "Reglas de security group sin tráfico en VPC Flow Logs en los últimos 90 días (alerta)", "Fecha de la última revisión de reglas registrada mayor a 6 meses (falla si excede)" ], "checks_azure": [ "NSG sin asociación a subred ni NIC (alerta)", "Reglas de NSG/Azure Firewall sin hits en los últimos 90 días según flow logs o logs de Azure Firewall (alerta)" ], "checks_gcp": [ "Firewall Insights: reglas sin uso (shadowed/unused) en los últimos 90 días (alerta)", "Reglas de firewall de VPC sin logging habilitado que impidan medir uso (alerta)" ], "evidencia": "Kyber genera el reporte semestral de reglas de NSC con uso y desviaciones; el cliente registra la revisión, decisiones y aprobación.", "evidencia_en": "Kyber generates the six-monthly NSC rules report with usage and deviations; the customer records the review, decisions and approval.", "limitaciones": "El escaneo no determina si una regla tiene justificación de negocio vigente ni sustituye la revisión humana y su aprobación.", "limitaciones_en": "Scanning cannot determine whether a rule still has a valid business justification, nor does it replace human review and approval.", "responsabilidad_compartida": "cliente", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.20", "5.36" ], "soc2_tsc": [ "CC6.6", "CC4.1" ], "cis_controls_v8": [ "4.2" ] } }, { "id": 10, "numero_regla": "1.2.8", "requisito": "1", "seccion": "1.2", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Configuración y mantenimiento de los controles de seguridad de la red (NSC)", "seccion_titulo_en": "Network security controls (NSCs) are configured and maintained", "descripcion_corta": "Archivos de configuración de NSC protegidos y consistentes con la configuración activa", "descripcion_larga": "Los archivos de configuración de los NSC deben estar protegidos contra acceso no autorizado y mantenerse coherentes con la configuración de red activa. Se considera archivo de configuración cualquier archivo o parámetro usado para configurar o sincronizar NSC, incluidos scripts, controles automatizados, infraestructura como código y respaldos o copias almacenadas remotamente. El objetivo es que los NSC no puedan definirse ni modificarse a partir de objetos de configuración no confiables.", "remediacion": "1. Mantener la configuración de red como código (Terraform, CloudFormation, Bicep/ARM, Deployment Manager) en repositorios con ramas protegidas, revisión obligatoria y acceso de mínimo privilegio. 2. Proteger los archivos de estado de IaC: bucket S3 / Storage Account / bucket de Cloud Storage privado, cifrado, con versionado y bloqueo, y acceso solo para el rol del pipeline. 3. Detectar deriva entre el código y la configuración activa (CloudFormation drift detection, terraform plan programado, Azure Policy, Config Connector) y corregirla. 4. Restringir los permisos IAM para modificar NSC (ec2:AuthorizeSecurityGroup*, Microsoft.Network/networkSecurityGroups/write, compute.firewalls.*) a roles de red y al pipeline. 5. Evidencia: controles de acceso al repositorio y al estado, reportes de deriva y política IAM restrictiva.", "descripcion_corta_en": "NSC configuration files secured and consistent with active configuration", "descripcion_larga_en": "NSC configuration files must be protected from unauthorized access and kept consistent with the active network configuration. Any file or setting used to configure or synchronize NSCs counts as a configuration file, including scripts, automated controls, infrastructure as code, and backups or copies stored remotely. The goal is that NSCs cannot be defined or modified using untrusted configuration objects.", "remediacion_en": "1. Keep network configuration as code (Terraform, CloudFormation, Bicep/ARM, Deployment Manager) in repositories with protected branches, mandatory review and least-privilege access. 2. Protect IaC state files: private, encrypted S3 bucket / Storage Account / Cloud Storage bucket with versioning and locking, accessible only to the pipeline role. 3. Detect drift between code and active configuration (CloudFormation drift detection, scheduled terraform plan, Azure Policy, Config Connector) and remediate it. 4. Restrict IAM permissions to modify NSCs (ec2:AuthorizeSecurityGroup*, Microsoft.Network/networkSecurityGroups/write, compute.firewalls.*) to network roles and the pipeline. 5. Evidence: repository and state access controls, drift reports and restrictive IAM policy.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 54, "pagina_pdf_es": 60 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Buckets S3 de estado de IaC con Block Public Access, cifrado y versionado habilitados (falla si no) [S3.8]", "Stacks de CloudFormation de red con estado de deriva DRIFTED (falla si existe)", "Políticas IAM que otorgan ec2:AuthorizeSecurityGroupIngress/ModifySecurityGroupRules a principales fuera de los roles de red o pipeline (falla si existe)", "AWS Config habilitado para registrar la configuración de NSC [Config.1]" ], "checks_azure": [ "Storage Accounts de estado de IaC con allowBlobPublicAccess = false, cifrado y soft delete/versionado (falla si no)", "Asignaciones de rol con permiso Microsoft.Network/networkSecurityGroups/write fuera de grupos autorizados (falla si existe)", "Resource locks CanNotDelete/ReadOnly en NSG y Azure Firewall del CDE (falla si faltan)" ], "checks_gcp": [ "Buckets de estado de IaC sin allUsers/allAuthenticatedUsers, con uniform bucket-level access y versionado (falla si no)", "Principales con compute.firewalls.create/update fuera de los grupos de red o cuentas de servicio del pipeline (falla si existe)" ], "evidencia": "Kyber reporta la protección de los repositorios de estado de IaC, permisos sobre NSC y deriva detectada; el cliente aporta los controles de acceso a sus repositorios de código.", "evidencia_en": "Kyber reports protection of IaC state stores, NSC permissions and detected drift; the customer provides access controls for its code repositories.", "limitaciones": "El escaneo no ve repositorios de código fuera de la nube (GitHub, GitLab) ni configuraciones de appliances de terceros, salvo que se integren por separado.", "limitaciones_en": "Scanning does not see code repositories outside the cloud (GitHub, GitLab) or third-party appliance configurations unless separately integrated.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.9", "8.20", "8.4" ], "soc2_tsc": [ "CC6.1", "CC8.1" ], "cis_controls_v8": [ "4.1", "4.2" ], "banxico_spei": [ "58a. I.A.f).7" ] } }, { "id": 11, "numero_regla": "1.3.1", "requisito": "1", "seccion": "1.3", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Acceso de red hacia y desde el CDE restringido", "seccion_titulo_en": "Network access to and from the CDE is restricted", "descripcion_corta": "Tráfico entrante al CDE restringido a lo necesario y todo lo demás denegado", "descripcion_larga": "El tráfico de entrada al entorno de datos del titular de la tarjeta (CDE) debe limitarse exclusivamente al que es necesario, y todo el resto debe denegarse de forma explícita. Esto aplica sin importar el origen del tráfico y debe estar definido en los estándares de configuración de los NSC y reflejado en su configuración. Una regla de denegación total explícita o implícita después de las reglas de permiso ayuda a evitar huecos involuntarios.", "remediacion": "1. Aislar el CDE en VPC/VNet/proyectos y subredes dedicadas. 2. Configurar security groups, NSG y reglas de firewall de VPC con orígenes específicos (otros security groups, etiquetas de red, rangos privados) y puertos mínimos; nunca 0.0.0.0/0 o ::/0 salvo en el balanceador público aprobado. 3. Mantener denegación por defecto: security groups solo con reglas de permiso, NACL con regla final deny, NSG con regla de baja prioridad DenyAll que anule AllowVnetInBound cuando aplique, y regla de entrada deny-all de baja prioridad en GCP. 4. Bloquear puertos administrativos (22, 3389) desde Internet y usar Session Manager, Azure Bastion o IAP. 5. Proteger la entrada pública con AWS WAF/Network Firewall, Azure Firewall/WAF o Cloud Armor. 6. Evidencia: estándar de NSC y exportación de reglas de entrada del CDE.", "descripcion_corta_en": "Inbound traffic to the CDE restricted to what is necessary and all else denied", "descripcion_larga_en": "Inbound traffic to the cardholder data environment (CDE) must be limited to only what is necessary, and all other traffic must be explicitly denied. This applies regardless of where traffic originates and must be defined in the NSC configuration standards and reflected in their configuration. An explicit deny-all or implicit deny after allow rules helps prevent unintended gaps.", "remediacion_en": "1. Isolate the CDE in dedicated VPCs/VNets/projects and subnets. 2. Configure security groups, NSGs and VPC firewall rules with specific sources (other security groups, network tags, private ranges) and minimal ports; never 0.0.0.0/0 or ::/0 except on the approved public load balancer. 3. Keep default deny: security groups with allow rules only, NACLs with a final deny rule, NSGs with a low-priority DenyAll rule overriding AllowVnetInBound where appropriate, and a low-priority deny-all ingress rule in GCP. 4. Block administrative ports (22, 3389) from the Internet and use Session Manager, Azure Bastion or IAP. 5. Protect public ingress with AWS WAF/Network Firewall, Azure Firewall/WAF or Cloud Armor. 6. Evidence: NSC standard and export of CDE inbound rules.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 55, "pagina_pdf_es": 61 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Security groups con 0.0.0.0/0 o ::/0 en puertos de administración remota 22/3389 (falla si existe) [EC2.53] [EC2.54]", "NACL que permiten 0.0.0.0/0 en puertos 22/3389 (falla si existe) [EC2.21]", "Security groups que permiten puertos de alto riesgo sin restricción (falla si existe) [EC2.19]", "Security group predeterminado sin reglas [EC2.2]", "Security groups de recursos etiquetados como CDE con orígenes 0.0.0.0/0 distintos al balanceador público aprobado (falla si existe)" ], "checks_azure": [ "Reglas de NSG con origen Any/Internet en puerto 3389 (falla si existe)", "Reglas de NSG con origen Any/Internet en puerto 22 (falla si existe)", "Subredes del CDE sin NSG asociado (falla si existe)", "Reglas de NSG de entrada con origen '*' hacia subredes del CDE (falla si existe)" ], "checks_gcp": [ "Reglas de firewall de VPC con sourceRanges 0.0.0.0/0 en tcp:22 (falla si existe)", "Reglas de firewall de VPC con sourceRanges 0.0.0.0/0 en tcp:3389 (falla si existe)", "Reglas de entrada con sourceRanges 0.0.0.0/0 hacia etiquetas o cuentas de servicio del CDE (falla si existe)", "Red 'default' con reglas default-allow-* en proyectos del CDE (falla si existe)" ], "evidencia": "Kyber genera la exportación de reglas de entrada hacia el CDE y el resultado de los checks; el cliente aporta el estándar que define el tráfico necesario.", "evidencia_en": "Kyber generates the export of inbound rules toward the CDE and the check results; the customer provides the standard defining necessary traffic.", "limitaciones": "Kyber no puede decidir qué tráfico interno es 'necesario' sin la lista aprobada; depende de que los recursos del CDE estén etiquetados.", "limitaciones_en": "Kyber cannot decide which internal traffic is 'necessary' without the approved list; it depends on CDE resources being tagged.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.20", "8.22" ], "soc2_tsc": [ "CC6.6" ], "cis_controls_v8": [ "12.2", "13.4" ], "banxico_spei": [ "58a. I.A.f).3", "58a. I.A.f).6" ] } }, { "id": 12, "numero_regla": "1.3.2", "requisito": "1", "seccion": "1.3", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Acceso de red hacia y desde el CDE restringido", "seccion_titulo_en": "Network access to and from the CDE is restricted", "descripcion_corta": "Tráfico saliente del CDE restringido a lo necesario y todo lo demás denegado", "descripcion_larga": "El tráfico de salida desde el CDE debe limitarse exclusivamente al que es necesario, y todo lo demás debe denegarse explícitamente, sin importar el destino. Esta restricción debe estar definida en los estándares de configuración de los NSC e implementada en ellos. El propósito es impedir que individuos maliciosos o componentes comprometidos dentro de la red se comuniquen con hosts externos no confiables.", "remediacion": "1. Eliminar la regla de salida por defecto 0.0.0.0/0 de los security groups del CDE y permitir solo destinos y puertos necesarios (p. ej. 443 hacia el procesador de pagos o hacia VPC endpoints). 2. En Azure, agregar una regla de salida DenyAll de baja prioridad que anule AllowInternetOutBound y forzar la salida por Azure Firewall con reglas FQDN; en GCP, crear una regla de egress deny-all de baja prioridad y permitir explícitamente lo necesario. 3. Centralizar la salida a Internet a través de AWS Network Firewall, Azure Firewall o Cloud NGFW/proxy con listas de FQDN permitidos; usar VPC endpoints, Private Link y Private Service Connect para servicios de la nube. 4. Habilitar Route 53 Resolver DNS Firewall o equivalente. 5. Evidencia: estándar y exportación de reglas de salida del CDE.", "descripcion_corta_en": "Outbound traffic from the CDE restricted to what is necessary and all else denied", "descripcion_larga_en": "Outbound traffic from the CDE must be limited to only what is necessary, and all other traffic must be explicitly denied, regardless of destination. This restriction must be defined in the NSC configuration standards and implemented in them. The purpose is to prevent malicious individuals or compromised components inside the network from communicating with untrusted external hosts.", "remediacion_en": "1. Remove the default 0.0.0.0/0 egress rule from CDE security groups and allow only necessary destinations and ports (e.g., 443 to the payment processor or to VPC endpoints). 2. In Azure, add a low-priority DenyAll outbound rule overriding AllowInternetOutBound and force egress through Azure Firewall with FQDN rules; in GCP, create a low-priority deny-all egress rule and explicitly allow what is needed. 3. Centralize Internet egress through AWS Network Firewall, Azure Firewall or Cloud NGFW/proxy with allowed FQDN lists; use VPC endpoints, Private Link and Private Service Connect for cloud services. 4. Enable Route 53 Resolver DNS Firewall or equivalent. 5. Evidence: standard and export of CDE outbound rules.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 56, "pagina_pdf_es": 62 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Security groups de recursos del CDE con salida 0.0.0.0/0 o ::/0 en todos los puertos/protocolos (falla si existe)", "Subredes del CDE con ruta 0.0.0.0/0 hacia NAT/Internet Gateway sin pasar por AWS Network Firewall (falla si existe)", "Route 53 Resolver DNS Firewall asociado a las VPC del CDE (falla si no)" ], "checks_azure": [ "NSG de subredes del CDE sin regla de salida que anule AllowInternetOutBound (falla si no existe)", "Subredes del CDE sin UDR 0.0.0.0/0 hacia Azure Firewall/NVA (falla si no existe)", "Reglas de salida de NSG con destino '*' y puerto '*' (falla si existe)" ], "checks_gcp": [ "Ausencia de regla de egress deny-all de baja prioridad en VPC del CDE (falla si no existe)", "Reglas de egress con destinationRanges 0.0.0.0/0 y protocolo all hacia etiquetas del CDE (falla si existe)", "VPC Service Controls con perímetro para proyectos del CDE (alerta si no existe)" ], "evidencia": "Kyber genera la exportación de reglas y rutas de salida del CDE con los hallazgos; el cliente aporta la lista de destinos necesarios.", "evidencia_en": "Kyber generates the export of CDE egress rules and routes with findings; the customer provides the list of necessary destinations.", "limitaciones": "El escaneo no puede validar la necesidad de negocio de cada destino ni inspeccionar filtrado de appliances de terceros (NVA) fuera de las APIs de la nube.", "limitaciones_en": "Scanning cannot validate the business need for each destination nor inspect filtering in third-party appliances (NVAs) beyond cloud APIs.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.20", "8.22" ], "soc2_tsc": [ "CC6.6" ], "cis_controls_v8": [ "12.2", "13.4" ], "banxico_spei": [ "58a. I.A.f).1", "58a. I.A.f).6" ] } }, { "id": 13, "numero_regla": "1.4.1", "requisito": "1", "seccion": "1.4", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Conexiones entre redes confiables y no confiables controladas", "seccion_titulo_en": "Network connections between trusted and untrusted networks are controlled", "descripcion_corta": "NSC implementados entre redes confiables y no confiables", "descripcion_larga": "Deben implementarse NSC entre las redes confiables y las no confiables, conforme a los estándares de configuración y a los diagramas de red documentados. Esto permite monitorear y controlar el acceso en cada conexión de entrada y salida de las redes confiables. Una DMZ que procese o transmita datos de cuenta (p. ej. un sitio de comercio electrónico) también se considera parte del CDE.", "remediacion": "1. Identificar cada frontera entre redes confiables (VPC/VNet internas) y no confiables (Internet, redes de socios, otras cuentas no gestionadas, VPN de terceros). 2. Asegurar que toda conexión a Internet pase por un NSC: security groups y NACL en subredes públicas, AWS Network Firewall o WAF en el perímetro; Azure Firewall/NSG/Application Gateway WAF; reglas de firewall de VPC, Cloud Armor o Cloud NGFW en GCP. 3. Diseñar una DMZ (subredes públicas solo con balanceadores/proxies) separada de las subredes privadas de aplicación y datos. 4. Evitar IP públicas directas en instancias del CDE. 5. Documentar estas fronteras en el estándar de NSC y en el diagrama de red (1.2.3). 6. Evidencia: diagrama, estándar y configuración de los NSC en cada frontera.", "descripcion_corta_en": "NSCs implemented between trusted and untrusted networks", "descripcion_larga_en": "NSCs must be implemented between trusted and untrusted networks, in line with documented configuration standards and network diagrams. This allows access to be monitored and controlled at every connection into and out of trusted networks. A DMZ that processes or transmits account data (e.g., an e-commerce website) is also considered part of the CDE.", "remediacion_en": "1. Identify every boundary between trusted networks (internal VPCs/VNets) and untrusted networks (Internet, partner networks, unmanaged accounts, third-party VPNs). 2. Ensure every Internet connection passes through an NSC: security groups and NACLs on public subnets, AWS Network Firewall or WAF at the edge; Azure Firewall/NSG/Application Gateway WAF; VPC firewall rules, Cloud Armor or Cloud NGFW in GCP. 3. Design a DMZ (public subnets containing only load balancers/proxies) separate from private application and data subnets. 4. Avoid direct public IPs on CDE instances. 5. Document these boundaries in the NSC standard and network diagram (1.2.3). 6. Evidence: diagram, standard and NSC configuration at each boundary.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 58, "pagina_pdf_es": 64 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Instancias EC2 con IP pública en subredes del CDE (falla si existe) [EC2.9]", "Subredes con asignación automática de IP pública habilitada en VPC del CDE (falla si existe) [EC2.15]", "ALB/CloudFront/API Gateway públicos sin AWS WAF asociado (falla si no)", "Conexiones VPN/VPC peering con cuentas externas sin NACL/security groups restrictivos en las subredes receptoras (alerta)" ], "checks_azure": [ "VM con IP pública en subredes del CDE (falla si existe)", "Subredes sin NSG asociado (falla si existe)", "Application Gateway/Front Door públicos sin WAF habilitado (falla si no)" ], "checks_gcp": [ "Instancias de Compute Engine con IP externa en subredes del CDE (falla si existe)", "Restricción de Organization Policy constraints/compute.vmExternalIpAccess aplicada a proyectos del CDE (falla si no)", "Backend services de balanceadores HTTP(S) externos sin política de Cloud Armor (falla si no)" ], "evidencia": "Kyber genera el mapa de fronteras confiable/no confiable con el NSC aplicado en cada una; el cliente aporta el estándar y el diagrama aprobado.", "evidencia_en": "Kyber generates a map of trusted/untrusted boundaries with the NSC applied at each; the customer provides the standard and approved diagram.", "limitaciones": "El escaneo no cubre fronteras fuera de la nube (oficinas, centros de datos) ni puede clasificar como confiables o no confiables redes de terceros sin información del cliente.", "limitaciones_en": "Scanning does not cover boundaries outside the cloud (offices, data centers) nor can it classify third-party networks as trusted or untrusted without customer input.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.20", "8.22" ], "soc2_tsc": [ "CC6.6" ], "cis_controls_v8": [ "12.2", "13.4" ], "banxico_spei": [ "58a. I.A.f).1" ] } }, { "id": 14, "numero_regla": "1.4.2", "requisito": "1", "seccion": "1.4", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Conexiones entre redes confiables y no confiables controladas", "seccion_titulo_en": "Network connections between trusted and untrusted networks are controlled", "descripcion_corta": "Entrada desde redes no confiables limitada a servicios públicos autorizados y respuestas con estado", "descripcion_larga": "El tráfico que entra desde redes no confiables hacia redes confiables solo puede ser: comunicaciones con componentes autorizados para ofrecer servicios, protocolos y puertos de acceso público; respuestas con estado (stateful) a comunicaciones iniciadas desde la red confiable; todo lo demás debe denegarse. El requisito se enfoca en las sesiones entre redes y no en protocolos específicos, por lo que no impide usar UDP u otros protocolos sin conexión si el NSC mantiene el estado.", "remediacion": "1. Exponer a Internet únicamente componentes autorizados (ALB/NLB, CloudFront, API Gateway, Application Gateway, Front Door, balanceadores de GCP) y documentar su autorización. 2. Usar NSC con estado para el resto: security groups (stateful), NSG (stateful) y reglas de firewall de VPC (stateful) que no permitan entrada desde Internet a servidores internos; las respuestas a conexiones salientes se permiten automáticamente. 3. Si se usan NACL (sin estado), limitar la entrada desde Internet a puertos efímeros solo en subredes con salida a Internet y documentar la compensación. 4. Para la salida de instancias privadas usar NAT Gateway, Azure NAT Gateway o Cloud NAT en lugar de IP públicas. 5. Evidencia: lista de componentes públicos autorizados y configuración de NSC que demuestre la denegación del resto.", "descripcion_corta_en": "Inbound traffic from untrusted networks restricted to authorized public services and stateful responses", "descripcion_larga_en": "Traffic entering trusted networks from untrusted networks may only be: communications with system components authorized to provide publicly accessible services, protocols and ports; stateful responses to communications initiated from the trusted network; everything else must be denied. The requirement focuses on sessions between networks rather than specific protocols, so it does not prohibit UDP or other connectionless protocols if the NSC maintains state.", "remediacion_en": "1. Expose to the Internet only authorized components (ALB/NLB, CloudFront, API Gateway, Application Gateway, Front Door, GCP load balancers) and document their authorization. 2. Use stateful NSCs for everything else: security groups, NSGs and VPC firewall rules (all stateful) that allow no Internet ingress to internal servers; responses to outbound connections are permitted automatically. 3. If NACLs (stateless) are used, limit Internet ingress to ephemeral ports only on subnets with Internet egress and document the trade-off. 4. For private instance egress, use NAT Gateway, Azure NAT Gateway or Cloud NAT instead of public IPs. 5. Evidence: list of authorized public components and NSC configuration showing all else is denied.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 59, "pagina_pdf_es": 65 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Recursos con exposición a Internet (IP pública + regla 0.0.0.0/0) no incluidos en la lista de componentes públicos autorizados (falla si existe)", "Instancias EC2 con IP pública (falla si no está autorizada) [EC2.9]", "Security groups que permiten entrada sin restricción solo en puertos autorizados [EC2.18]", "Instancias RDS, OpenSearch o Redshift accesibles públicamente (falla si existe) [RDS.2] [Redshift.1]" ], "checks_azure": [ "NIC/VM con IP pública y regla de NSG que permite Internet no incluidas en la lista autorizada (falla si existe)", "Servicios PaaS con publicNetworkAccess = Enabled sin restricción de red (falla si no está autorizado)" ], "checks_gcp": [ "Instancias con accessConfigs (IP externa) y reglas de firewall 0.0.0.0/0 no incluidas en la lista autorizada (falla si existe)", "Cloud SQL con IP pública y authorizedNetworks 0.0.0.0/0 (falla si existe)" ], "evidencia": "Kyber genera el listado de todos los componentes expuestos a Internet con sus puertos; el cliente aporta la lista de componentes autorizados para acceso público.", "evidencia_en": "Kyber generates the list of all Internet-exposed components and their ports; the customer provides the list of components authorized for public access.", "limitaciones": "El comportamiento con estado de los NSC nativos lo garantiza el proveedor de nube; el escaneo no valida la autorización de negocio de cada componente público ni appliances de terceros.", "limitaciones_en": "Stateful behavior of native NSCs is guaranteed by the cloud provider; scanning does not validate the business authorization of each public component or third-party appliances.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.20", "8.22" ], "soc2_tsc": [ "CC6.6" ], "cis_controls_v8": [ "12.2", "13.4" ] } }, { "id": 15, "numero_regla": "1.4.3", "requisito": "1", "seccion": "1.4", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Conexiones entre redes confiables y no confiables controladas", "seccion_titulo_en": "Network connections between trusted and untrusted networks are controlled", "descripcion_corta": "Medidas antispoofing para detectar y bloquear IP origen falsificadas hacia la red confiable", "descripcion_larga": "Deben implementarse medidas contra la suplantación (antispoofing) que detecten y bloqueen paquetes con direcciones IP de origen falsificadas que intenten entrar a la red confiable, por ejemplo direcciones internas que llegan desde Internet. Muchos productos traen esta protección activada por defecto y a veces no es configurable, por lo que debe confirmarse con la documentación del fabricante.", "remediacion": "1. Confirmar en la documentación del proveedor de nube que la red virtual descarta paquetes con IP de origen no asignada a la interfaz (AWS VPC, Azure VNet y GCP VPC lo hacen por defecto) y referenciar sus reportes de cumplimiento. 2. Mantener habilitada la verificación de origen/destino (source/destination check) en EC2 y deshabilitar IP forwarding en NIC de Azure y canIpForward en GCP, salvo en NAT/firewalls virtuales aprobados y documentados. 3. En appliances virtuales o AWS Network Firewall/Azure Firewall, habilitar reglas que bloqueen en el perímetro rangos RFC 1918 y bogons provenientes de Internet. 4. Habilitar Cloud Armor/WAF con reglas de reputación de IP cuando aplique. 5. Evidencia: documentación del proveedor, configuraciones de source/dest check e IP forwarding y reglas antispoofing de los appliances.", "descripcion_corta_en": "Anti-spoofing measures to detect and block forged source IPs entering the trusted network", "descripcion_larga_en": "Anti-spoofing measures must be implemented to detect and block packets with forged source IP addresses trying to enter the trusted network, for example internal addresses arriving from the Internet. Many products enable this protection by default and it may not be configurable, so it should be confirmed against vendor documentation.", "remediacion_en": "1. Confirm in the cloud provider documentation that the virtual network drops packets whose source IP is not assigned to the interface (AWS VPC, Azure VNet and GCP VPC do this by default) and reference their compliance reports. 2. Keep source/destination check enabled on EC2 and disable IP forwarding on Azure NICs and canIpForward on GCP, except on approved and documented NAT/virtual firewalls. 3. On virtual appliances or AWS Network Firewall/Azure Firewall, enable rules blocking RFC 1918 and bogon ranges arriving from the Internet at the edge. 4. Enable Cloud Armor/WAF with IP reputation rules where applicable. 5. Evidence: provider documentation, source/dest check and IP forwarding settings, and appliance anti-spoofing rules.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 60, "pagina_pdf_es": 66 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Instancias EC2 con SourceDestCheck = false que no estén etiquetadas como NAT/firewall aprobado (falla si existe)", "Reglas de AWS Network Firewall que descartan tráfico entrante desde Internet con origen RFC 1918 (alerta si no existen y hay appliance perimetral)" ], "checks_azure": [ "NIC con enableIPForwarding = true no etiquetadas como NVA aprobado (falla si existe)", "Azure Firewall con modo de inteligencia de amenazas en Alert and deny (alerta si no)" ], "checks_gcp": [ "Instancias con canIpForward = true no etiquetadas como appliance aprobado (falla si existe)", "Restricción de Organization Policy constraints/compute.vmCanIpForward aplicada en proyectos del CDE (alerta si no)" ], "evidencia": "Kyber reporta las interfaces con reenvío de IP o verificación de origen deshabilitada; el cliente referencia los reportes del proveedor de nube (AWS Artifact, Microsoft Service Trust Portal, Google Compliance Reports Manager) para el antispoofing nativo de la red virtual.", "evidencia_en": "Kyber reports interfaces with IP forwarding enabled or source check disabled; the customer references the cloud provider reports (AWS Artifact, Microsoft Service Trust Portal, Google Compliance Reports Manager) for native virtual network anti-spoofing.", "limitaciones": "El antispoofing de la red virtual lo implementa el proveedor y no es observable por API; el escaneo solo detecta configuraciones del cliente que lo debilitan.", "limitaciones_en": "Virtual network anti-spoofing is implemented by the provider and is not observable via API; scanning only detects customer configurations that weaken it.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.20" ], "soc2_tsc": [ "CC6.6" ], "cis_controls_v8": [ "13.4" ] } }, { "id": 16, "numero_regla": "1.4.4", "requisito": "1", "seccion": "1.4", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Conexiones entre redes confiables y no confiables controladas", "seccion_titulo_en": "Network connections between trusted and untrusted networks are controlled", "descripcion_corta": "Componentes que almacenan datos del titular de la tarjeta no accesibles directamente desde redes no confiables", "descripcion_larga": "Los componentes del sistema que almacenan datos del titular de la tarjeta (como bases de datos o archivos) no deben ser accesibles directamente desde redes no confiables. Esto debe estar documentado en los diagramas de red y de flujo de datos e implementado en los NSC. No aplica al almacenamiento en memoria volátil, pero sí cuando la memoria se usa como almacenamiento persistente (p. ej. disco RAM); en memoria volátil los datos solo pueden permanecer el tiempo necesario para el proceso de negocio.", "remediacion": "1. Ubicar bases de datos y almacenamiento con datos del titular de la tarjeta en subredes privadas sin ruta a Internet y sin IP pública. 2. AWS: RDS/Aurora/Redshift/OpenSearch con PubliclyAccessible = false, S3 Block Public Access a nivel cuenta y bucket, snapshots de EBS/RDS no públicos y acceso por VPC endpoints con políticas de bucket restrictivas. 3. Azure: Storage, Azure SQL y Cosmos DB con publicNetworkAccess = Disabled y Private Endpoints; allowBlobPublicAccess = false. 4. GCP: Cloud SQL solo con IP privada, buckets sin allUsers/allAuthenticatedUsers con Public Access Prevention aplicado, y VPC Service Controls. 5. Documentar en los diagramas que estos componentes no son accesibles desde redes no confiables. 6. Evidencia: diagramas y configuración de red/acceso de cada almacén de datos.", "descripcion_corta_en": "System components storing cardholder data not directly accessible from untrusted networks", "descripcion_larga_en": "System components that store cardholder data (such as databases or files) must not be directly accessible from untrusted networks. This must be documented in the network and data-flow diagrams and implemented in the NSCs. It does not apply to volatile memory storage, but does apply when memory is used as persistent storage (e.g., RAM disk); in volatile memory, data may remain only as long as the business process requires.", "remediacion_en": "1. Place databases and storage holding cardholder data in private subnets with no Internet route and no public IP. 2. AWS: RDS/Aurora/Redshift/OpenSearch with PubliclyAccessible = false, S3 Block Public Access at account and bucket level, non-public EBS/RDS snapshots, and access via VPC endpoints with restrictive bucket policies. 3. Azure: Storage, Azure SQL and Cosmos DB with publicNetworkAccess = Disabled and Private Endpoints; allowBlobPublicAccess = false. 4. GCP: Cloud SQL with private IP only, buckets without allUsers/allAuthenticatedUsers with Public Access Prevention enforced, and VPC Service Controls. 5. Document in the diagrams that these components are not reachable from untrusted networks. 6. Evidence: diagrams and network/access configuration of every data store.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 61, "pagina_pdf_es": 67 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Instancias RDS accesibles públicamente (falla si existe) [RDS.2]", "Snapshots de RDS públicos (falla si existe) [RDS.1]", "Snapshots de EBS restaurables públicamente (falla si existe) [EC2.1]", "S3 Block Public Access habilitado a nivel cuenta y bucket [S3.1] [S3.8]", "Buckets S3 que permiten lectura o escritura pública (falla si existe) [S3.2] [S3.3]", "Clústeres Redshift accesibles públicamente (falla si existe) [Redshift.1]" ], "checks_azure": [ "Storage Accounts con allowBlobPublicAccess = true o publicNetworkAccess = Enabled sin reglas de red (falla si existe)", "Azure SQL/Cosmos DB con publicNetworkAccess = Enabled o regla de firewall 0.0.0.0-255.255.255.255 (falla si existe)", "Bases de datos del CDE sin Private Endpoint (falla si no)" ], "checks_gcp": [ "Cloud SQL con IP pública y authorizedNetworks 0.0.0.0/0 (falla si existe)", "Cloud SQL con IP pública habilitada en instancias del CDE (falla si existe)", "Buckets de Cloud Storage con allUsers o allAuthenticatedUsers (falla si existe)", "Public Access Prevention aplicado en buckets del CDE (falla si no)" ], "evidencia": "Kyber genera el listado de almacenes de datos y su exposición de red; con snapshots de discos puede ayudar a identificar dónde hay datos del titular de la tarjeta. El cliente aporta los diagramas que documentan el aislamiento.", "evidencia_en": "Kyber generates the list of data stores and their network exposure; with disk snapshots it can help identify where cardholder data resides. The customer provides diagrams documenting the isolation.", "limitaciones": "El escaneo depende de que los almacenes con datos del titular de la tarjeta estén identificados o etiquetados; no evalúa almacenamiento en memoria ni sistemas fuera de la nube.", "limitaciones_en": "Scanning depends on cardholder data stores being identified or tagged; it does not assess in-memory storage or non-cloud systems.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.20", "8.22", "8.3" ], "soc2_tsc": [ "CC6.1", "CC6.6" ], "cis_controls_v8": [ "3.3", "12.2" ] } }, { "id": 17, "numero_regla": "1.4.5", "requisito": "1", "seccion": "1.4", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Conexiones entre redes confiables y no confiables controladas", "seccion_titulo_en": "Network connections between trusted and untrusted networks are controlled", "descripcion_corta": "Divulgación de direcciones IP internas e información de enrutamiento limitada a partes autorizadas", "descripcion_larga": "La revelación de direcciones IP internas y de información de enrutamiento debe limitarse a partes autorizadas, tanto por configuración de los NSC como por controles documentados. Los métodos pueden variar según la tecnología (IPv4 o IPv6), por ejemplo NAT, colocar componentes detrás de proxies o NSC, filtrar anuncios de rutas de redes internas con direccionamiento registrado y usar direcciones RFC 1918 o extensiones de privacidad de IPv6 (RFC 4941) al salir a Internet.", "remediacion": "1. Usar direccionamiento privado (RFC 1918) en VPC/VNet y salir a Internet mediante NAT Gateway, Azure NAT Gateway o Cloud NAT; publicar servicios solo a través de balanceadores o proxies. 2. Usar zonas DNS privadas (Route 53 private hosted zones, Azure Private DNS, Cloud DNS privado) para nombres internos y verificar que las zonas públicas no publiquen registros hacia IP privadas. 3. Filtrar anuncios BGP en VPN/Direct Connect/ExpressRoute/Interconnect para no propagar rutas internas a terceros no autorizados. 4. Eliminar cabeceras que revelen IP internas en respuestas de balanceadores, API gateways y aplicaciones (X-Forwarded-For hacia clientes, Server, mensajes de error). 5. Restringir con IAM quién puede leer la topología de red (describe/list de VPC, subredes, rutas). 6. Evidencia: configuración de NAT/DNS/BGP y pruebas que muestren que no se divulgan IP internas.", "descripcion_corta_en": "Disclosure of internal IP addresses and routing information limited to authorized parties", "descripcion_larga_en": "Disclosure of internal IP addresses and routing information must be limited to authorized parties, both through NSC configuration and documented controls. Methods vary by technology (IPv4 or IPv6), for example NAT, placing components behind proxies or NSCs, filtering route advertisements for internal networks using registered addressing, and using RFC 1918 addresses or IPv6 privacy extensions (RFC 4941) when going to the Internet.", "remediacion_en": "1. Use private (RFC 1918) addressing in VPCs/VNets and reach the Internet via NAT Gateway, Azure NAT Gateway or Cloud NAT; publish services only through load balancers or proxies. 2. Use private DNS zones (Route 53 private hosted zones, Azure Private DNS, private Cloud DNS) for internal names and verify that public zones do not publish records pointing to private IPs. 3. Filter BGP advertisements on VPN/Direct Connect/ExpressRoute/Interconnect so internal routes are not propagated to unauthorized third parties. 4. Strip headers revealing internal IPs from load balancer, API gateway and application responses (X-Forwarded-For toward clients, Server, error messages). 5. Restrict via IAM who can read network topology (describe/list of VPCs, subnets, routes). 6. Evidence: NAT/DNS/BGP configuration and tests showing internal IPs are not disclosed.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 62, "pagina_pdf_es": 68 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Zonas alojadas públicas de Route 53 con registros A/AAAA que apuntan a direcciones RFC 1918 (falla si existe)", "Instancias del CDE con IP pública en lugar de salida por NAT Gateway (falla si existe) [EC2.9]", "Balanceadores internos de aplicaciones del CDE configurados como internet-facing (falla si no está autorizado)" ], "checks_azure": [ "Zonas DNS públicas de Azure con registros hacia IP privadas (falla si existe)", "VM del CDE con IP pública en lugar de salida por NAT Gateway/Azure Firewall (falla si existe)" ], "checks_gcp": [ "Zonas públicas de Cloud DNS con registros hacia IP privadas (falla si existe)", "Instancias del CDE con IP externa en lugar de salida por Cloud NAT (falla si existe)", "Cloud Routers con anuncios personalizados que incluyen rangos internos del CDE hacia peers externos (alerta)" ], "evidencia": "Kyber reporta registros DNS públicos con IP privadas, exposición directa de IP y anuncios de rutas visibles por API; el cliente aporta pruebas de capa de aplicación (cabeceras, errores) y la configuración de equipos on-prem.", "evidencia_en": "Kyber reports public DNS records pointing to private IPs, direct IP exposure and route advertisements visible via API; the customer provides application-layer tests (headers, errors) and on-prem device configuration.", "limitaciones": "El escaneo no detecta fugas de IP internas en respuestas de la aplicación (cabeceras, mensajes de error) ni en routers on-prem; eso requiere pruebas dinámicas o pentest.", "limitaciones_en": "Scanning does not detect internal IP leakage in application responses (headers, error messages) or on-prem routers; that requires dynamic testing or a pentest.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.20", "8.22" ], "soc2_tsc": [ "CC6.6" ], "cis_controls_v8": [ "12.2" ] } }, { "id": 18, "numero_regla": "1.5.1", "requisito": "1", "seccion": "1.5", "categoria": "Requisito 1: Instalar y mantener los controles de seguridad de la red", "categoria_en": "Requirement 1: Install and Maintain Network Security Controls", "seccion_titulo": "Riesgos de dispositivos conectados a redes no confiables y al CDE mitigados", "seccion_titulo_en": "Risks from devices connecting to both untrusted networks and the CDE are mitigated", "descripcion_corta": "Controles de seguridad en dispositivos que se conectan a redes no confiables y al CDE", "descripcion_larga": "Cualquier dispositivo informático, propiedad de la empresa o del empleado, que se conecte tanto a redes no confiables (incluido Internet) como al CDE debe tener controles de seguridad que cumplan: parámetros de configuración específicos definidos para evitar que se introduzcan amenazas a la red de la entidad; controles en ejecución activa; y controles que el usuario no pueda alterar, salvo autorización documentada de la dirección caso por caso y por tiempo limitado. Si se deshabilitan temporalmente, debe existir autorización formal y pueden requerirse medidas adicionales durante ese periodo.", "remediacion": "1. Inventariar laptops, estaciones y dispositivos móviles (corporativos y BYOD) que acceden al CDE, incluidas las cuentas de administradores de nube. 2. Definir una línea base: EDR/antimalware, firewall personal, cifrado de disco, parches, bloqueo de pantalla, y prohibición de split tunneling en la VPN (o arranque en VPN siempre activa). 3. Gestionarlos con MDM/UEM (Intune, Jamf, Workspace ONE) con perfiles que impidan al usuario desactivar los controles y alertas cuando se desactiven. 4. Exigir acceso al CDE solo desde dispositivos que cumplan la política (Conditional Access de Microsoft Entra ID, Google Context-Aware Access, AWS Verified Access) y vía VPN/ZTNA sin split tunneling (AWS Client VPN, Azure VPN Gateway). 5. Documentar y aprobar por tiempo limitado cualquier excepción. 6. Evidencia: política, reportes de cumplimiento del MDM/EDR y registros de excepciones aprobadas.", "descripcion_corta_en": "Security controls on devices connecting to both untrusted networks and the CDE", "descripcion_larga_en": "Any computing device, company- or employee-owned, that connects both to untrusted networks (including the Internet) and to the CDE must have security controls such that: specific configuration settings are defined to keep threats from entering the entity's network; controls are actively running; and controls cannot be changed by the user unless management documents and authorizes it case by case for a limited time. If controls are temporarily disabled, formal authorization is required and additional measures may be needed during that period.", "remediacion_en": "1. Inventory laptops, workstations and mobile devices (corporate and BYOD) that access the CDE, including cloud administrators' devices. 2. Define a baseline: EDR/anti-malware, personal firewall, disk encryption, patching, screen lock, and no split tunneling on the VPN (or always-on VPN at boot). 3. Manage them with MDM/UEM (Intune, Jamf, Workspace ONE) using profiles that prevent users from disabling controls and alert when they are disabled. 4. Allow CDE access only from policy-compliant devices (Microsoft Entra ID Conditional Access, Google Context-Aware Access, AWS Verified Access) and via VPN/ZTNA without split tunneling (AWS Client VPN, Azure VPN Gateway). 5. Document and approve any exception for a limited time. 6. Evidence: policy, MDM/EDR compliance reports and approved exception records.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 63, "pagina_pdf_es": 69 }, "kyber_cobertura": { "tipo": "fuera_alcance_agentless", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "El cliente aporta la política de dispositivos, reportes de cumplimiento del MDM/EDR, configuración de VPN sin split tunneling y registros de excepciones autorizadas.", "evidencia_en": "The customer provides the device policy, MDM/EDR compliance reports, VPN configuration without split tunneling and authorized exception records.", "limitaciones": "Los controles viven en endpoints (laptops, móviles) fuera de la cuenta de nube; el escaneo agentless no puede verificarlos. A lo sumo puede revisarse por separado la configuración de split tunneling de AWS Client VPN o del gateway VPN, que no demuestra el cumplimiento del requisito.", "limitaciones_en": "Controls live on endpoints (laptops, mobiles) outside the cloud account; agentless scanning cannot verify them. At most, the split-tunnel setting of AWS Client VPN or the VPN gateway can be reviewed separately, which does not demonstrate compliance with the requirement.", "responsabilidad_compartida": "cliente", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.1", "8.7", "6.7" ], "soc2_tsc": [ "CC6.7", "CC6.8" ], "cis_controls_v8": [ "4.5", "10.1", "12.7" ] } }, { "id": 19, "numero_regla": "2.1.1", "requisito": "2", "seccion": "2.1", "categoria": "Requisito 2: Aplicar configuraciones seguras a todos los componentes del sistema", "categoria_en": "Requirement 2: Apply Secure Configurations to All System Components", "seccion_titulo": "Procesos y mecanismos de configuración segura definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for secure configurations are defined and understood", "descripcion_corta": "Políticas y procedimientos operativos del Requisito 2 documentados, vigentes, en uso y conocidos", "descripcion_larga": "La entidad debe contar con políticas de seguridad y procedimientos operativos para todas las actividades del Requisito 2 (configuración segura de los componentes del sistema). Deben estar documentados, mantenerse actualizados ante cambios de procesos, tecnologías u objetivos de negocio (no solo de forma periódica), aplicarse en la operación y ser conocidos por todas las partes afectadas.", "remediacion": "1. Redactar una política de configuración segura y procedimientos que cubran estándares de hardening por tipo de componente (imágenes de VM, contenedores, bases de datos administradas, servicios PaaS, cuentas y consolas de nube), gestión de cuentas predeterminadas, servicios innecesarios e inseguros y acceso administrativo cifrado. 2. Versionar los documentos con dueño, fecha y aprobador; revisarlos al menos anualmente y tras cambios relevantes. 3. Publicarlos y obtener acuse de lectura del personal de plataforma, DevOps y administración. 4. Vincularlos a la operación real (pipelines de imágenes doradas, políticas como código). 5. Evidencia: política aprobada, historial de versiones, acuses y registros de su aplicación.", "descripcion_corta_en": "Requirement 2 security policies and operational procedures documented, current, in use and known", "descripcion_larga_en": "The entity must have security policies and operational procedures for all Requirement 2 activities (secure configuration of system components). They must be documented, kept up to date as processes, technologies or business objectives change (not only periodically), applied in operations and known to all affected parties.", "remediacion_en": "1. Write a secure configuration policy and procedures covering hardening standards per component type (VM images, containers, managed databases, PaaS services, cloud accounts and consoles), vendor default account management, unnecessary and insecure services, and encrypted administrative access. 2. Version the documents with owner, date and approver; review at least annually and after significant changes. 3. Publish them and collect read acknowledgments from platform, DevOps and administration staff. 4. Tie them to real operations (golden image pipelines, policy as code). 5. Evidence: approved policy, version history, acknowledgments and records of their application.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 66, "pagina_pdf_es": 72 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Política de configuración segura y procedimientos aprobados, historial de versiones, acuses de lectura y registros de uso. Kyber puede generar la plantilla mediante el generador de políticas.", "evidencia_en": "Approved secure configuration policy and procedures, version history, read acknowledgments and usage records. Kyber can produce the template through its policy generator.", "limitaciones": "El escaneo no puede verificar que las políticas estén vigentes, en uso ni que el personal las conozca.", "limitaciones_en": "Scanning cannot verify that policies are current, in use or known to staff.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.1", "5.37", "8.9" ], "soc2_tsc": [ "CC5.3", "CC2.2" ], "cis_controls_v8": [ "4.1" ] } }, { "id": 20, "numero_regla": "2.1.2", "requisito": "2", "seccion": "2.1", "categoria": "Requisito 2: Aplicar configuraciones seguras a todos los componentes del sistema", "categoria_en": "Requirement 2: Apply Secure Configurations to All System Components", "seccion_titulo": "Procesos y mecanismos de configuración segura definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for secure configurations are defined and understood", "descripcion_corta": "Roles y responsabilidades del Requisito 2 documentados, asignados y comprendidos", "descripcion_larga": "Las funciones y responsabilidades para ejecutar las actividades del Requisito 2 deben estar documentadas, asignadas y ser comprendidas por el personal. Pueden documentarse en las políticas o por separado, por ejemplo con una matriz RACI, para que las tareas de configuración segura tengan responsables que rindan cuentas por su operación continua.", "remediacion": "1. Elaborar una matriz RACI para el Requisito 2: definición y actualización de estándares de hardening, construcción de imágenes doradas, gestión de cuentas predeterminadas, revisión de servicios habilitados y de parámetros de seguridad de servicios de nube. 2. Asignar responsables y suplentes por plataforma (AWS, Azure, GCP, Kubernetes, bases de datos). 3. Obtener acuse de aceptación y revisar la matriz ante cambios organizacionales. 4. Evidencia: matriz aprobada, acuses y entrevistas al personal.", "descripcion_corta_en": "Requirement 2 roles and responsibilities documented, assigned and understood", "descripcion_larga_en": "Roles and responsibilities for carrying out Requirement 2 activities must be documented, assigned and understood by personnel. They may be documented in policies or separately, for example in a RACI matrix, so that secure configuration tasks have owners accountable for their continuous operation.", "remediacion_en": "1. Build a RACI matrix for Requirement 2: defining and updating hardening standards, building golden images, managing vendor default accounts, reviewing enabled services and cloud service security parameters. 2. Assign owners and backups per platform (AWS, Azure, GCP, Kubernetes, databases). 3. Obtain acceptance acknowledgments and update the matrix upon organizational changes. 4. Evidence: approved matrix, acknowledgments and staff interviews.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 67, "pagina_pdf_es": 73 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Matriz RACI o documento de roles aprobado, acuses de aceptación y registros de entrevistas.", "evidencia_en": "Approved RACI matrix or roles document, acceptance acknowledgments and interview records.", "limitaciones": "No es verificable por escaneo; depende de documentación y entrevistas.", "limitaciones_en": "Not verifiable through scanning; relies on documentation and interviews.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.2", "5.3" ], "soc2_tsc": [ "CC1.3", "CC1.4" ], "cis_controls_v8": [] } }, { "id": 21, "numero_regla": "2.2.1", "requisito": "2", "seccion": "2.2", "categoria": "Requisito 2: Aplicar configuraciones seguras a todos los componentes del sistema", "categoria_en": "Requirement 2: Apply Secure Configurations to All System Components", "seccion_titulo": "Componentes del sistema configurados y administrados de forma segura", "seccion_titulo_en": "System components are configured and managed securely", "descripcion_corta": "Estándares de configuración (hardening) desarrollados, implementados y mantenidos para todos los componentes", "descripcion_larga": "Deben desarrollarse, implementarse y mantenerse estándares de configuración que: cubran todos los componentes del sistema; atiendan todas las vulnerabilidades de seguridad conocidas; sean coherentes con estándares de hardening aceptados por la industria o recomendaciones del fabricante; se actualicen cuando se identifiquen nuevas vulnerabilidades según el requisito 6.3.1; y se apliquen a los sistemas nuevos, verificándose antes o inmediatamente después de conectarlos a producción. Fuentes de referencia incluyen CIS, ISO, NIST, Cloud Security Alliance y los fabricantes.", "remediacion": "1. Adoptar CIS Benchmarks (sistemas operativos, Kubernetes/EKS/AKS/GKE, bases de datos) y CIS Foundations Benchmarks de AWS, Azure y GCP como base, con desviaciones documentadas. 2. Construir imágenes doradas endurecidas (EC2 Image Builder, Azure Image Builder/Compute Gallery, imágenes personalizadas de GCP) y permitir solo imágenes aprobadas en producción. 3. Aplicar políticas como código para servicios de nube: AWS Config conformance packs y Security Hub, Azure Policy/Defender for Cloud, Security Command Center y Organization Policies. 4. Verificar el cumplimiento en el despliegue (pipeline) y continuamente; actualizar los estándares al publicarse nuevas vulnerabilidades (6.3.1). 5. Evidencia: estándares aprobados, reportes de cumplimiento por componente y registros de verificación previa a producción.", "descripcion_corta_en": "Configuration (hardening) standards developed, implemented and maintained for all components", "descripcion_larga_en": "Configuration standards must be developed, implemented and maintained so that they: cover all system components; address all known security vulnerabilities; are consistent with industry-accepted hardening standards or vendor recommendations; are updated as new vulnerabilities are identified per Requirement 6.3.1; and are applied to new systems, verified before or immediately after they connect to production. Reference sources include CIS, ISO, NIST, the Cloud Security Alliance and vendors.", "remediacion_en": "1. Adopt CIS Benchmarks (operating systems, Kubernetes/EKS/AKS/GKE, databases) and the CIS AWS, Azure and GCP Foundations Benchmarks as the baseline, with documented deviations. 2. Build hardened golden images (EC2 Image Builder, Azure Image Builder/Compute Gallery, GCP custom images) and allow only approved images in production. 3. Apply policy as code to cloud services: AWS Config conformance packs and Security Hub, Azure Policy/Defender for Cloud, Security Command Center and Organization Policies. 4. Verify compliance at deployment (pipeline) and continuously; update standards when new vulnerabilities are published (6.3.1). 5. Evidence: approved standards, per-component compliance reports and pre-production verification records.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 68, "pagina_pdf_es": 74 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "AWS Security Hub habilitado con el estándar PCI DSS v4.0.1 y/o CIS AWS Foundations en todas las cuentas y regiones", "AWS Config habilitado en todas las regiones [Config.1]", "Evaluación CIS Benchmark del sistema operativo sobre snapshots de discos de instancias del CDE (falla por cada control L1 no cumplido)", "Instancias EC2 lanzadas desde AMI no incluidas en la lista de imágenes aprobadas (falla si existe)" ], "checks_azure": [ "Microsoft Defender for Cloud habilitado con la iniciativa PCI DSS v4 asignada en suscripciones del CDE", "Evaluación CIS Benchmark del sistema operativo sobre snapshots de discos de VM del CDE (falla por control no cumplido)", "VM creadas desde imágenes fuera de la Compute Gallery aprobada (falla si existe)" ], "checks_gcp": [ "Security Command Center habilitado (Security Health Analytics) a nivel organización", "Evaluación CIS Benchmark del sistema operativo sobre snapshots de discos de instancias del CDE (falla por control no cumplido)", "Organization Policy constraints/compute.trustedImageProjects aplicada en proyectos del CDE (falla si no)" ], "evidencia": "Kyber genera reportes de cumplimiento contra CIS Benchmarks para servicios de nube y sistemas operativos (vía snapshots); el cliente aporta los estándares aprobados y el proceso de actualización según 6.3.1.", "evidencia_en": "Kyber generates compliance reports against CIS Benchmarks for cloud services and operating systems (via snapshots); the customer provides approved standards and the 6.3.1 update process.", "limitaciones": "El escaneo no confirma que los estándares cubran todos los componentes (p. ej. dispositivos on-prem, SaaS) ni que se actualicen ante nuevas vulnerabilidades; algunas configuraciones en tiempo de ejecución no se observan en snapshots.", "limitaciones_en": "Scanning does not confirm that standards cover all components (e.g., on-prem devices, SaaS) or are updated for new vulnerabilities; some runtime settings are not observable in snapshots.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.9", "8.8" ], "soc2_tsc": [ "CC7.1", "CC8.1" ], "cis_controls_v8": [ "4.1" ], "banxico_spei": [ "58a. I.A.b).4" ] }, "mapeo_ucf": [ { "clave": "UCF-CFG-001", "relacion": "equivalent", "cobertura_pct": 90 } ] }, { "id": 22, "numero_regla": "2.2.2", "requisito": "2", "seccion": "2.2", "categoria": "Requisito 2: Aplicar configuraciones seguras a todos los componentes del sistema", "categoria_en": "Requirement 2: Apply Secure Configurations to All System Components", "seccion_titulo": "Componentes del sistema configurados y administrados de forma segura", "seccion_titulo_en": "System components are configured and managed securely", "descripcion_corta": "Cuentas predeterminadas del proveedor: cambiar contraseña si se usan, eliminar o deshabilitar si no", "descripcion_larga": "Las cuentas predeterminadas del proveedor deben gestionarse así: si se van a usar, su contraseña predeterminada se cambia conforme al requisito 8.3.6; si no se van a usar, se eliminan o deshabilitan. Aplica a todas las cuentas y contraseñas predeterminadas (sistemas operativos, software de seguridad, cuentas de aplicación y sistema, terminales POS, aplicaciones de pago, SNMP), incluso cuando el componente no está instalado en el entorno de la entidad, como software del CDE consumido como servicio en la nube.", "remediacion": "1. Inventariar las cuentas predeterminadas por plataforma: usuario raíz de AWS, cuentas locales de SO, usuarios maestros de bases de datos (postgres, sa, root, admin), cuentas de consolas de appliances y SaaS del CDE, comunidades SNMP 'public/private'. 2. Usuario raíz de AWS: sin llaves de acceso, con MFA y uso solo para tareas que lo requieran; en Azure y GCP, limitar cuentas de emergencia y propietarios a nivel organización. 3. Usar nombres de administrador personalizados en RDS/Azure SQL y almacenar contraseñas fuertes (8.3.6) en AWS Secrets Manager, Azure Key Vault o Secret Manager con rotación. 4. Deshabilitar cuentas locales no usadas (p. ej. disableLocalAccounts en AKS, cuentas de SO por defecto) y no usar la cuenta de servicio predeterminada de Compute Engine. 5. Revisar imágenes doradas para que no contengan credenciales por defecto. 6. Evidencia: inventario de cuentas predeterminadas con su estado y configuraciones que lo demuestren.", "descripcion_corta_en": "Vendor default accounts: change password if used, remove or disable if not", "descripcion_larga_en": "Vendor default accounts must be managed as follows: if they will be used, the default password is changed per Requirement 8.3.6; if they will not be used, they are removed or disabled. This applies to all vendor default accounts and passwords (operating systems, security software, application and system accounts, POS terminals, payment applications, SNMP), even when the component is not installed in the entity's environment, such as CDE software consumed as a cloud subscription service.", "remediacion_en": "1. Inventory default accounts per platform: AWS root user, local OS accounts, database master users (postgres, sa, root, admin), appliance and CDE SaaS console accounts, SNMP 'public/private' communities. 2. AWS root user: no access keys, MFA enabled and used only for tasks that require it; in Azure and GCP, limit break-glass accounts and organization-level owners. 3. Use custom administrator usernames in RDS/Azure SQL and store strong passwords (8.3.6) in AWS Secrets Manager, Azure Key Vault or Secret Manager with rotation. 4. Disable unused local accounts (e.g., disableLocalAccounts on AKS, default OS accounts) and do not use the Compute Engine default service account. 5. Review golden images so they contain no default credentials. 6. Evidence: inventory of default accounts with their status and configurations proving it.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 69, "pagina_pdf_es": 75 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Usuario raíz de AWS sin llaves de acceso (falla si existen) [IAM.4]", "Usuario raíz de AWS con MFA de hardware habilitado [IAM.6]", "Clústeres e instancias RDS con nombre de administrador distinto al predeterminado del motor [RDS.24] [RDS.25]", "Snapshots de disco: cuentas locales predeterminadas del SO con contraseña habilitada o comunidades SNMP 'public'/'private' en archivos de configuración (falla si existe)" ], "checks_azure": [ "AKS con disableLocalAccounts = true (falla si no)", "Azure SQL con login de administrador con nombre predeterminado (admin, sa, administrator) (falla si existe)", "Snapshots de disco de VM: cuentas locales predeterminadas habilitadas o credenciales por defecto (falla si existe)" ], "checks_gcp": [ "Instancias de Compute Engine que usan la cuenta de servicio predeterminada (falla si existe)", "Cloud SQL MySQL con usuario 'root' que permite conexiones desde cualquier host (falla si existe)", "Snapshots de disco: cuentas locales predeterminadas habilitadas o credenciales por defecto (falla si existe)" ], "evidencia": "Kyber genera el listado de cuentas predeterminadas detectadas en la nube y en snapshots de discos con su estado; el cliente aporta evidencia de cambio de contraseñas y de cuentas en SaaS, POS y appliances fuera de la nube.", "evidencia_en": "Kyber generates the list of default accounts detected in the cloud and in disk snapshots with their status; the customer provides evidence of password changes and of accounts in SaaS, POS and appliances outside the cloud.", "limitaciones": "El escaneo no puede comprobar que una contraseña predeterminada haya sido cambiada cuando el hash no está disponible, ni cubre terminales POS, SaaS o appliances fuera de la cuenta de nube.", "limitaciones_en": "Scanning cannot prove a default password was changed when the hash is not available, nor does it cover POS terminals, SaaS or appliances outside the cloud account.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.17", "8.2", "8.9" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "4.7" ] } }, { "id": 23, "numero_regla": "2.2.3", "requisito": "2", "seccion": "2.2", "categoria": "Requisito 2: Aplicar configuraciones seguras a todos los componentes del sistema", "categoria_en": "Requirement 2: Apply Secure Configurations to All System Components", "seccion_titulo": "Componentes del sistema configurados y administrados de forma segura", "seccion_titulo_en": "System components are configured and managed securely", "descripcion_corta": "Funciones principales con distintos niveles de seguridad separadas, aisladas o protegidas al nivel más alto", "descripcion_larga": "Las funciones principales que requieren distintos niveles de seguridad deben gestionarse mediante una de estas opciones: una sola función principal por componente del sistema; o aislamiento entre funciones con distintos niveles de seguridad en un mismo componente; o protección de todas ellas al nivel que exige la función más exigente. En entornos virtualizados, los niveles de seguridad deben identificarse y gestionarse por cada componente virtual (máquina virtual, contenedor, instancia).", "remediacion": "1. Diseñar una función principal por componente: instancias, VM, funciones serverless o servicios separados para web, aplicación y base de datos (p. ej. RDS/Azure SQL/Cloud SQL administrados en lugar de bases de datos en el servidor web). 2. En contenedores, separar cargas por nivel de seguridad en clústeres, node pools o namespaces distintos con NetworkPolicies, sin contenedores privilegiados ni uso de red/PID del host, y aplicar Pod Security Standards 'restricted'. 3. Separar entornos del CDE en cuentas, suscripciones o proyectos dedicados. 4. Si coexisten funciones en un mismo componente, documentar la justificación y endurecer todas al nivel de la más exigente. 5. Evidencia: estándar de configuración con la regla de función principal e inventario que muestre la función de cada componente.", "descripcion_corta_en": "Primary functions with different security levels separated, isolated or secured to the highest level", "descripcion_larga_en": "Primary functions requiring different security levels must be managed through one of these options: only one primary function per system component; or isolation between functions with different security levels on the same component; or securing all of them to the level required by the most demanding function. In virtualized environments, security levels must be identified and managed for each virtual component (virtual machine, container, instance).", "remediacion_en": "1. Design one primary function per component: separate instances, VMs, serverless functions or services for web, application and database (e.g., managed RDS/Azure SQL/Cloud SQL instead of databases on the web server). 2. In containers, separate workloads by security level into distinct clusters, node pools or namespaces with NetworkPolicies, no privileged containers or host network/PID use, and enforce Pod Security Standards 'restricted'. 3. Separate CDE environments into dedicated accounts, subscriptions or projects. 4. If functions coexist on one component, document the justification and harden all of them to the strictest level. 5. Evidence: configuration standard with the primary function rule and an inventory showing each component's function.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 70, "pagina_pdf_es": 77 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Instancias EC2 cuyo security group expone a la vez puertos web (80/443) y de base de datos (3306/5432/1433/27017) (falla si existe)", "Definiciones de tarea de ECS con privileged = true (falla si existe) [ECS.4]", "Snapshots de disco: servidor web y motor de base de datos instalados y habilitados en la misma instancia del CDE (falla si existe)" ], "checks_azure": [ "VM cuyo NSG expone a la vez puertos web y de base de datos (falla si existe)", "AKS: pods privilegiados o con hostNetwork/hostPID (falla si existe)", "Snapshots de disco: servidor web y motor de base de datos en la misma VM del CDE (falla si existe)" ], "checks_gcp": [ "Instancias con reglas de firewall que exponen a la vez puertos web y de base de datos (falla si existe)", "GKE: pods privilegiados o con hostNetwork/hostPID (falla si existe)", "Snapshots de disco: servidor web y motor de base de datos en la misma instancia del CDE (falla si existe)" ], "evidencia": "Kyber genera el inventario de componentes con su función inferida (servicios, puertos, paquetes) y señala coexistencias; el cliente documenta la función principal y la justificación de excepciones.", "evidencia_en": "Kyber generates a component inventory with its inferred function (services, ports, packages) and flags coexistence; the customer documents the primary function and justification for exceptions.", "limitaciones": "La función principal es una decisión de diseño; el escaneo solo la infiere de servicios y puertos. El aislamiento del hipervisor entre instancias lo garantiza el proveedor de nube.", "limitaciones_en": "The primary function is a design decision; scanning only infers it from services and ports. Hypervisor isolation between instances is guaranteed by the cloud provider.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.22", "8.9" ], "soc2_tsc": [ "CC6.1", "CC6.6" ], "cis_controls_v8": [ "4.1", "12.2" ] } }, { "id": 24, "numero_regla": "2.2.4", "requisito": "2", "seccion": "2.2", "categoria": "Requisito 2: Aplicar configuraciones seguras a todos los componentes del sistema", "categoria_en": "Requirement 2: Apply Secure Configurations to All System Components", "seccion_titulo": "Componentes del sistema configurados y administrados de forma segura", "seccion_titulo_en": "System components are configured and managed securely", "descripcion_corta": "Solo servicios, protocolos, «demonios» y funciones necesarios; lo innecesario eliminado o deshabilitado", "descripcion_larga": "Únicamente deben estar habilitados los servicios, protocolos, daemons y funciones necesarios, documentados en los estándares de configuración; toda funcionalidad innecesaria debe eliminarse o deshabilitarse. La funcionalidad innecesaria puede incluir scripts, controladores, características, subsistemas, sistemas de archivos, interfaces (USB, Bluetooth) y servidores web no requeridos.", "remediacion": "1. Documentar en el estándar de cada tipo de componente los servicios y funciones permitidos. 2. Construir imágenes mínimas (distroless o imágenes base reducidas para contenedores, AMI/imágenes endurecidas) y eliminar paquetes como telnet-server, ftp, rsh, servidores web o compiladores no requeridos. 3. Deshabilitar en servicios administrados las funciones no usadas: API de consulta pública, endpoints heredados, acceso SSH a nodos, consola serial, extensiones de base de datos innecesarias. 4. Escanear periódicamente snapshots de discos e imágenes de contenedores para detectar servicios habilitados fuera de la lista y corregir en la imagen dorada. 5. Evidencia: lista de servicios permitidos y reporte de servicios realmente habilitados por componente.", "descripcion_corta_en": "Only necessary services, protocols, daemons and functions enabled; unnecessary functionality removed or disabled", "descripcion_larga_en": "Only the necessary services, protocols, daemons and functions, documented in the configuration standards, may be enabled; all unnecessary functionality must be removed or disabled. Unnecessary functionality may include scripts, drivers, features, subsystems, file systems, interfaces (USB, Bluetooth) and unneeded web servers.", "remediacion_en": "1. Document in each component type's standard the allowed services and functions. 2. Build minimal images (distroless or slim container base images, hardened AMIs/images) and remove packages such as telnet-server, ftp, rsh, web servers or compilers that are not required. 3. Disable unused features in managed services: public query APIs, legacy endpoints, node SSH access, serial console, unnecessary database extensions. 4. Periodically scan disk snapshots and container images to detect services enabled outside the list and fix them in the golden image. 5. Evidence: list of allowed services and report of services actually enabled per component.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 72, "pagina_pdf_es": 79 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Snapshots de disco de EC2: servicios habilitados al arranque no incluidos en la lista permitida (telnet, ftp, rsh, xinetd, etc.) (falla si existe)", "Imágenes de ECR con paquetes de servicios innecesarios según el escaneo de imágenes (alerta)", "Security groups que abren puertos no incluidos en la lista de servicios permitidos del componente (falla si existe)" ], "checks_azure": [ "Snapshots de disco de VM: servicios habilitados no incluidos en la lista permitida (falla si existe)", "Extensiones de VM instaladas no aprobadas (falla si existe)", "App Service con remote debugging habilitado (falla si existe)" ], "checks_gcp": [ "Snapshots de disco: servicios habilitados no incluidos en la lista permitida (falla si existe)", "Instancias con metadata serial-port-enable = true (falla si existe)", "GKE con legacy ABAC o dashboard de Kubernetes habilitados (falla si existe)" ], "evidencia": "Kyber genera, a partir de snapshots e imágenes, el listado de servicios y paquetes habilitados por componente y lo compara con la lista permitida del cliente.", "evidencia_en": "Kyber generates, from snapshots and images, the list of enabled services and packages per component and compares it with the customer's allowed list.", "limitaciones": "El análisis de snapshots muestra servicios configurados para iniciar, no necesariamente los que corren en memoria; interfaces físicas (USB, Bluetooth) no aplican a instancias de nube y deben cubrirse en endpoints.", "limitaciones_en": "Snapshot analysis shows services configured to start, not necessarily those running in memory; physical interfaces (USB, Bluetooth) do not apply to cloud instances and must be covered on endpoints.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.9", "8.19" ], "soc2_tsc": [ "CC7.1", "CC6.8" ], "cis_controls_v8": [ "4.8" ], "banxico_spei": [ "58a. I.A.b).4" ] } }, { "id": 25, "numero_regla": "2.2.5", "requisito": "2", "seccion": "2.2", "categoria": "Requisito 2: Aplicar configuraciones seguras a todos los componentes del sistema", "categoria_en": "Requirement 2: Apply Secure Configurations to All System Components", "seccion_titulo": "Componentes del sistema configurados y administrados de forma segura", "seccion_titulo_en": "System components are configured and managed securely", "descripcion_corta": "Servicios, protocolos o daemons inseguros con justificación de negocio y controles adicionales", "descripcion_larga": "Si existen servicios, protocolos o daemons inseguros, debe documentarse su justificación de negocio y deben documentarse e implementarse características de seguridad adicionales que reduzcan el riesgo de su uso. Para identificar qué es inseguro se recomienda consultar guías como las de NIST, ENISA y OWASP.", "remediacion": "1. Identificar en los componentes servicios y protocolos inseguros: Telnet, FTP, TFTP, rlogin/rsh, SNMP v1/v2c, SMBv1, HTTP sin cifrar, TLS 1.0/1.1, cifrados débiles. 2. Sustituirlos por alternativas seguras (SSH, SFTP/FTPS, SNMPv3, SMBv3 con cifrado, HTTPS con TLS 1.2+). 3. Si alguno es indispensable, documentar la justificación de negocio, la aceptación del riesgo y controles adicionales: aislamiento en subred dedicada, origen restringido, túnel VPN/TLS, monitoreo reforzado. 4. Aplicar en los servicios de nube políticas TLS mínimas (ELB security policies, minimumTlsVersion de Azure, SSL policies de GCP). 5. Evidencia: inventario de servicios inseguros con justificación y configuraciones de los controles adicionales.", "descripcion_corta_en": "Insecure services, protocols or daemons with business justification and additional security features", "descripcion_larga_en": "If any insecure services, protocols or daemons are present, their business justification must be documented, and additional security features that reduce the risk of using them must be documented and implemented. Guidance from sources such as NIST, ENISA and OWASP should be used to identify what is insecure.", "remediacion_en": "1. Identify insecure services and protocols on components: Telnet, FTP, TFTP, rlogin/rsh, SNMP v1/v2c, SMBv1, cleartext HTTP, TLS 1.0/1.1, weak ciphers. 2. Replace them with secure alternatives (SSH, SFTP/FTPS, SNMPv3, encrypted SMBv3, HTTPS with TLS 1.2+). 3. If any is indispensable, document the business justification, risk acceptance and additional controls: isolation in a dedicated subnet, restricted source, VPN/TLS tunnel, enhanced monitoring. 4. Enforce minimum TLS policies on cloud services (ELB security policies, Azure minimumTlsVersion, GCP SSL policies). 5. Evidence: inventory of insecure services with justification and configurations of the additional controls.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 73, "pagina_pdf_es": 80 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Snapshots de disco de EC2: telnetd, vsftpd, tftp, rsh o SNMP v1/v2c habilitados (falla si existe sin justificación)", "Listeners de ELB con políticas que permiten TLS 1.0/1.1 (falla si existe)", "Listeners HTTP de ALB sin redirección a HTTPS [ELB.1]", "AWS Transfer Family con protocolo FTP habilitado (falla si existe)" ], "checks_azure": [ "Storage Accounts con minimumTlsVersion distinto de TLS1_2 o supportsHttpsTrafficOnly = false (falla si existe)", "App Service con minTlsVersion menor a 1.2, httpsOnly = false o ftpsState = AllAllowed (falla si existe)", "Snapshots de disco de VM: SMBv1, Telnet o FTP habilitados (falla si existe sin justificación)" ], "checks_gcp": [ "Políticas SSL de balanceadores con minTlsVersion menor a TLS_1_2 o perfil COMPATIBLE (falla si existe)", "Cloud SQL sin sslMode ENCRYPTED_ONLY / requireSsl (falla si existe)", "Snapshots de disco: Telnet, FTP o SNMP v1/v2c habilitados (falla si existe sin justificación)" ], "evidencia": "Kyber genera el listado de servicios y protocolos inseguros detectados en configuración y snapshots; el cliente aporta la justificación de negocio y la documentación de los controles adicionales.", "evidencia_en": "Kyber generates the list of insecure services and protocols detected in configuration and snapshots; the customer provides the business justification and documentation of additional controls.", "limitaciones": "El escaneo no evalúa si la justificación de negocio es válida ni la eficacia de controles compensatorios fuera de la nube.", "limitaciones_en": "Scanning does not assess whether the business justification is valid nor the effectiveness of compensating controls outside the cloud.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.9", "8.20", "8.24" ], "soc2_tsc": [ "CC6.7", "CC6.6" ], "cis_controls_v8": [ "4.8", "3.10" ], "banxico_spei": [ "58a. I.A.b).1" ] } }, { "id": 26, "numero_regla": "2.2.6", "requisito": "2", "seccion": "2.2", "categoria": "Requisito 2: Aplicar configuraciones seguras a todos los componentes del sistema", "categoria_en": "Requirement 2: Apply Secure Configurations to All System Components", "seccion_titulo": "Componentes del sistema configurados y administrados de forma segura", "seccion_titulo_en": "System components are configured and managed securely", "descripcion_corta": "Parámetros de seguridad del sistema configurados para evitar su uso indebido", "descripcion_larga": "Los parámetros de seguridad de los componentes del sistema deben configurarse para impedir su uso indebido, conforme a los estándares de configuración. Los administradores y responsables de seguridad deben conocer los parámetros de seguridad comunes de cada tipo de componente, incluida la configuración segura de los parámetros usados para acceder a portales y consolas de nube.", "remediacion": "1. Definir en los estándares los parámetros de seguridad por servicio, tomando como base los CIS Foundations Benchmarks y las recomendaciones del proveedor. 2. AWS: IMDSv2 obligatorio, cifrado de EBS por defecto, política de contraseñas de IAM, S3 Block Public Access, cifrado y registro en servicios administrados. 3. Azure: Defender for Cloud con recomendaciones atendidas, Storage con acceso seguro, discos cifrados, configuración segura de Microsoft Entra ID (security defaults/Conditional Access). 4. GCP: OS Login habilitado, bloqueo de llaves SSH a nivel proyecto, consola serial deshabilitada, Shielded VM. 5. Aplicar como guardas (SCP, Azure Policy, Organization Policy) y evaluar continuamente; capacitar a los administradores en estos parámetros. 6. Evidencia: estándar con los parámetros, reporte de cumplimiento y registros de capacitación.", "descripcion_corta_en": "System security parameters configured to prevent misuse", "descripcion_larga_en": "System component security parameters must be configured to prevent misuse, in line with the configuration standards. Administrators and security managers must know the common security parameters for each component type, including secure settings for parameters used to access cloud portals and consoles.", "remediacion_en": "1. Define security parameters per service in the standards, based on CIS Foundations Benchmarks and provider recommendations. 2. AWS: enforce IMDSv2, default EBS encryption, IAM password policy, S3 Block Public Access, encryption and logging on managed services. 3. Azure: Defender for Cloud recommendations addressed, secure transfer on Storage, encrypted disks, secure Microsoft Entra ID settings (security defaults/Conditional Access). 4. GCP: OS Login enabled, project-wide SSH keys blocked, serial console disabled, Shielded VM. 5. Enforce as guardrails (SCPs, Azure Policy, Organization Policy) and evaluate continuously; train administrators on these parameters. 6. Evidence: standard listing the parameters, compliance report and training records.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 74, "pagina_pdf_es": 81 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Instancias EC2 con IMDSv2 obligatorio (HttpTokens = required) [EC2.8]", "Cifrado de EBS por defecto habilitado en cada región [EC2.7]", "Política de contraseñas de IAM conforme al estándar (falla si no existe o es débil)", "Funciones Lambda con runtimes soportados [Lambda.2]" ], "checks_azure": [ "Recomendaciones de Microsoft Defender for Cloud con severidad alta sin atender en suscripciones del CDE (falla si existe)", "VM con cifrado en host o ADE habilitado (falla si no)", "Storage Accounts con supportsHttpsTrafficOnly = true y allowSharedKeyAccess = false (falla si no)" ], "checks_gcp": [ "Instancias con enable-oslogin = true (falla si no)", "Instancias con block-project-ssh-keys = true (falla si no)", "Instancias con serial-port-enable distinto de true (falla si está habilitado)", "Instancias con Shielded VM (Secure Boot, vTPM, integrity monitoring) habilitado (falla si no)" ], "evidencia": "Kyber genera el reporte de parámetros de seguridad configurados por servicio frente al estándar; el cliente aporta los estándares y evidencia de conocimiento del personal.", "evidencia_en": "Kyber generates the report of security parameters configured per service against the standard; the customer provides the standards and evidence of staff knowledge.", "limitaciones": "El escaneo no evalúa el conocimiento del personal (entrevistas) ni parámetros de componentes fuera de la nube.", "limitaciones_en": "Scanning does not assess staff knowledge (interviews) nor parameters of components outside the cloud.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.9" ], "soc2_tsc": [ "CC7.1", "CC6.1" ], "cis_controls_v8": [ "4.1" ] } }, { "id": 27, "numero_regla": "2.2.7", "requisito": "2", "seccion": "2.2", "categoria": "Requisito 2: Aplicar configuraciones seguras a todos los componentes del sistema", "categoria_en": "Requirement 2: Apply Secure Configurations to All System Components", "seccion_titulo": "Componentes del sistema configurados y administrados de forma segura", "seccion_titulo_en": "System components are configured and managed securely", "descripcion_corta": "Acceso administrativo sin consola cifrado con criptografía sólida", "descripcion_larga": "Todo acceso administrativo que no sea por consola física (incluido el remoto) debe cifrarse con criptografía sólida. Incluye el acceso administrativo por interfaces web y por interfaces de programación de aplicaciones (API), así como tecnologías de acceso alterno como gestión fuera de banda, IPMI o KVM remotos. No deben estar disponibles servicios de inicio de sesión remoto inseguros y la criptografía debe implementarse según buenas prácticas del sector o recomendaciones del fabricante.", "remediacion": "1. Prohibir protocolos administrativos en texto claro (Telnet, rlogin, HTTP, FTP, SNMP v1/v2c) y versiones débiles (SSH v1, TLS < 1.2). 2. Administrar instancias mediante AWS Systems Manager Session Manager, Azure Bastion o IAP TCP forwarding de GCP en lugar de exponer SSH/RDP; si se usa SSH/RDP, restringir el origen y forzar cifrado fuerte (RDP con NLA/TLS). 3. Exigir HTTPS con TLS 1.2+ en consolas de aplicaciones administrativas y APIs (políticas de seguridad de ELB/API Gateway, minTlsVersion de App Service, SSL policies de GCP). 4. Verificar que paneles de administración de bases de datos, Kubernetes (endpoint privado de EKS/AKS/GKE) y appliances usen solo canales cifrados. 5. Las consolas y APIs del proveedor de nube usan TLS por defecto; referenciar sus reportes. 6. Evidencia: estándar, configuraciones y observación de un inicio de sesión administrativo.", "descripcion_corta_en": "Non-console administrative access encrypted with strong cryptography", "descripcion_larga_en": "All administrative access other than via a physical console (including remote access) must be encrypted using strong cryptography. This includes administrative access through browser-based interfaces and APIs, as well as alternative access technologies such as out-of-band management, IPMI or remote KVM. Insecure remote login services must not be available and cryptography must be implemented according to industry best practices or vendor recommendations.", "remediacion_en": "1. Prohibit cleartext administrative protocols (Telnet, rlogin, HTTP, FTP, SNMP v1/v2c) and weak versions (SSH v1, TLS < 1.2). 2. Administer instances through AWS Systems Manager Session Manager, Azure Bastion or GCP IAP TCP forwarding instead of exposing SSH/RDP; if SSH/RDP is used, restrict sources and enforce strong encryption (RDP with NLA/TLS). 3. Require HTTPS with TLS 1.2+ on administrative application consoles and APIs (ELB/API Gateway security policies, App Service minTlsVersion, GCP SSL policies). 4. Verify that database admin panels, Kubernetes (private EKS/AKS/GKE endpoint) and appliances use only encrypted channels. 5. Cloud provider consoles and APIs use TLS by default; reference their reports. 6. Evidence: standard, configurations and observation of an administrative login.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 75, "pagina_pdf_es": 82 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Security groups que permiten Telnet (23) desde cualquier origen (falla si existe)", "Security groups con 0.0.0.0/0 o ::/0 en 22/3389 (falla si existe) [EC2.53] [EC2.54]", "Listeners de ELB/API Gateway administrativos con TLS menor a 1.2 o HTTP sin redirección (falla si existe) [ELB.1]", "Endpoint público del API server de EKS habilitado sin restricción de CIDR (falla si existe) [EKS.1]", "Snapshots de disco: sshd con Protocol 1 o cifrados débiles, o telnetd habilitado (falla si existe)" ], "checks_azure": [ "Reglas de NSG que permiten 22/3389 desde Internet en lugar de Azure Bastion (falla si existe)", "App Service/Function Apps con httpsOnly = false o minTlsVersion menor a 1.2 (falla si existe)", "AKS sin API server privado o authorizedIPRanges (falla si existe)", "Snapshots de disco de VM: RDP sin NLA o SSH con cifrados débiles (falla si existe)" ], "checks_gcp": [ "Reglas de firewall que permiten 22/3389 desde 0.0.0.0/0 en lugar del rango de IAP 35.235.240.0/20 (falla si existe)", "GKE sin private endpoint o sin master authorized networks (falla si existe)", "Políticas SSL con minTlsVersion menor a TLS_1_2 en balanceadores de consolas administrativas (falla si existe)", "Snapshots de disco: sshd con cifrados débiles o telnetd habilitado (falla si existe)" ], "evidencia": "Kyber reporta los canales administrativos expuestos y su cifrado; el cliente aporta el estándar, la observación de un inicio de sesión administrativo y referencias a los reportes del proveedor para el cifrado de consolas y APIs de nube.", "evidencia_en": "Kyber reports exposed administrative channels and their encryption; the customer provides the standard, observation of an administrative login and references to provider reports for cloud console and API encryption.", "limitaciones": "El escaneo no observa sesiones reales ni cubre interfaces fuera de banda de hardware on-prem; el cifrado de las consolas y APIs del proveedor de nube es heredado.", "limitaciones_en": "Scanning does not observe real sessions nor cover out-of-band interfaces of on-prem hardware; encryption of the cloud provider consoles and APIs is inherited.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "8.5", "8.20" ], "soc2_tsc": [ "CC6.1", "CC6.7" ], "cis_controls_v8": [ "3.10", "4.6" ], "banxico_spei": [ "58a. I.A.b).1" ] } }, { "id": 28, "numero_regla": "3.1.1", "requisito": "3", "seccion": "3.1", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Procesos y mecanismos para proteger los datos de cuenta almacenados", "seccion_titulo_en": "Processes and mechanisms for protecting stored account data", "descripcion_corta": "Políticas y procedimientos del Requisito 3 documentados, vigentes, en uso y conocidos", "descripcion_larga": "La entidad debe contar con las políticas de seguridad y los procedimientos operativos que exige el Requisito 3 (protección de los datos de cuenta almacenados). Dichos documentos deben estar por escrito, actualizarse cuando cambien procesos o tecnologías, aplicarse en la operación diaria y haberse comunicado a todo el personal involucrado. El objetivo es que las expectativas y controles para proteger los datos almacenados sean repetibles y coherentes con la intención de la dirección.", "remediacion": "1) Redacte una política de protección de datos de cuenta almacenados que cubra retención y eliminación, prohibición de SAD, enmascaramiento, cifrado del PAN y gestión de claves (KMS, Key Vault, Cloud KMS). 2) Derive procedimientos operativos (p. ej. alta de llaves CMK, rotación, revisión trimestral de retención, uso de Macie/Purview/Sensitive Data Protection). 3) Establezca control de versiones, dueño y fecha de revisión (al menos anual y tras cada cambio relevante). 4) Publíquelos en un repositorio accesible y registre la confirmación de lectura del personal afectado. 5) Conserve como evidencia el documento aprobado, historial de versiones y acuses de lectura para el QSA.", "descripcion_corta_en": "Requirement 3 security policies and procedures documented, current, in use and known", "descripcion_larga_en": "The entity must maintain the security policies and operational procedures required by Requirement 3 (protection of stored account data). These documents must be written down, updated when processes or technologies change, actually followed in day-to-day operations, and communicated to all personnel involved. The goal is that expectations and controls for protecting stored data are repeatable and aligned with management's intent.", "remediacion_en": "1) Write a stored account data protection policy covering retention and disposal, SAD prohibition, masking, PAN encryption and key management (KMS, Key Vault, Cloud KMS). 2) Derive operating procedures (e.g., CMK creation, rotation, quarterly retention review, use of Macie/Purview/Sensitive Data Protection). 3) Set version control, an owner and a review date (at least annually and after every relevant change). 4) Publish them in an accessible repository and record read acknowledgments from affected personnel. 5) Keep the approved document, version history and acknowledgments as evidence for the QSA.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 79, "pagina_pdf_es": 86 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Política y procedimientos del Requisito 3 aprobados, con historial de versiones y acuses de lectura; Kyber puede generar la plantilla de política.", "evidencia_en": "Approved Requirement 3 policy and procedures with version history and read acknowledgments; Kyber can generate the policy template.", "limitaciones": "El escaneo no puede verificar que las políticas estén en uso ni que el personal las conozca.", "limitaciones_en": "Scanning cannot verify that policies are in use or known by personnel.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.1", "5.37" ], "soc2_tsc": [ "CC5.3", "CC2.2" ], "cis_controls_v8": [ "3.1" ] } }, { "id": 29, "numero_regla": "3.1.2", "requisito": "3", "seccion": "3.1", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Procesos y mecanismos para proteger los datos de cuenta almacenados", "seccion_titulo_en": "Processes and mechanisms for protecting stored account data", "descripcion_corta": "Roles y responsabilidades del Requisito 3 documentados, asignados y comprendidos", "descripcion_larga": "Las funciones y responsabilidades para ejecutar las actividades del Requisito 3 (retención de datos, cifrado, gestión de claves, enmascaramiento) deben estar documentadas, asignadas a personas concretas y entendidas por ellas. Esto evita que actividades críticas queden sin dueño. Puede documentarse dentro de las políticas o en documentos separados, por ejemplo con una matriz RACI.", "remediacion": "1) Elabore una matriz RACI para las actividades del Requisito 3: dueño de la política de retención, custodios de claves KMS/Key Vault/Cloud KMS, responsables de escaneos de PAN (Macie, Purview, Sensitive Data Protection) y de la revisión trimestral de retención. 2) Relacione cada rol con los roles de IAM/RBAC correspondientes en la nube. 3) Obtenga la aceptación firmada o electrónica de cada responsable. 4) Revise la matriz al menos una vez al año y en cada cambio de personal. 5) Evidencia: matriz RACI aprobada, acuses de aceptación y entrevistas con el personal.", "descripcion_corta_en": "Requirement 3 roles and responsibilities documented, assigned and understood", "descripcion_larga_en": "Roles and responsibilities for carrying out Requirement 3 activities (data retention, encryption, key management, masking) must be documented, assigned to specific people and understood by them. This prevents critical activities from going unowned. They may be documented within policies or in separate documents, for example using a RACI matrix.", "remediacion_en": "1) Build a RACI matrix for Requirement 3 activities: retention policy owner, KMS/Key Vault/Cloud KMS key custodians, owners of PAN discovery scans (Macie, Purview, Sensitive Data Protection) and of the quarterly retention review. 2) Map each role to the corresponding cloud IAM/RBAC roles. 3) Obtain signed or electronic acceptance from each owner. 4) Review the matrix at least annually and upon any personnel change. 5) Evidence: approved RACI matrix, acceptance records and personnel interviews.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 80, "pagina_pdf_es": 87 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Matriz RACI del Requisito 3 y acuses de aceptación de responsabilidades; Kyber puede generar la plantilla.", "evidencia_en": "Requirement 3 RACI matrix and responsibility acknowledgments; Kyber can generate the template.", "limitaciones": "No verificable por escaneo; depende de documentación y entrevistas.", "limitaciones_en": "Not verifiable by scanning; relies on documentation and interviews.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.2", "5.3" ], "soc2_tsc": [ "CC1.3", "CC5.3" ], "cis_controls_v8": [] } }, { "id": 30, "numero_regla": "3.2.1", "requisito": "3", "seccion": "3.2", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Almacenamiento de datos de cuenta reducido al mínimo", "seccion_titulo_en": "Storage of account data is kept to a minimum", "descripcion_corta": "Almacenamiento de datos de cuenta minimizado mediante políticas de retención y eliminación", "descripcion_larga": "La entidad debe minimizar el almacenamiento de datos de cuenta con políticas, procedimientos y procesos de retención y eliminación que abarquen todas las ubicaciones donde se guardan, incluidos los SAD guardados antes de completar la autorización. Debe limitar cantidad y tiempo de retención a lo exigido por requisitos legales, regulatorios o de negocio, definir para cada dato un periodo de retención con justificación documentada, contar con métodos de eliminación segura o que hagan irrecuperables los datos, y verificar al menos cada tres meses que los datos vencidos se eliminaron de forma segura. Cuando un TPSP (p. ej. un proveedor de nube) almacena los datos, la entidad debe entender cómo se cumple, incluyendo la eliminación en todas las regiones. El punto sobre SAD previo a la autorización fue mejor práctica hasta el 31 de marzo de 2025 y ahora es obligatorio.", "remediacion": "1) Identifique todas las ubicaciones de datos de cuenta con Amazon Macie (descubrimiento automatizado), Microsoft Purview (escaneo de Storage/SQL) o GCP Sensitive Data Protection, incluyendo respaldos, snapshots, bitácoras y réplicas multirregión. 2) Documente por tipo de dato el periodo de retención y su justificación. 3) Automatice la eliminación: S3 Lifecycle (Expiration y NoncurrentVersionExpiration), DynamoDB TTL, retención de AWS Backup/RDS, Azure Blob lifecycle management, Cloud Storage Object Lifecycle, y retención acotada en CloudWatch Logs/Log Analytics/Cloud Logging para logs con datos de cuenta. 4) Use eliminación criptográfica (borrado de la CMK dedicada) o servicios con borrado seguro cuando no sea posible sobrescribir. 5) Ejecute y registre una revisión trimestral que confirme que no hay datos fuera de plazo (reporte de Macie/Purview/DLP firmado). 6) Evidencia: política de retención, configuraciones de ciclo de vida y reportes trimestrales.", "descripcion_corta_en": "Account data storage minimized through retention and disposal policies", "descripcion_larga_en": "The entity must keep account data storage to a minimum through retention and disposal policies, procedures and processes that cover every location where it is stored, including SAD held before authorization completes. Storage amount and retention time must be limited to legal, regulatory or business needs, each data element must have a defined retention period with a documented business justification, secure deletion or methods that render data unrecoverable must exist, and at least every three months the entity must verify that data past its retention period was securely removed. Where a TPSP (e.g., a cloud provider) stores the data, the entity must understand how this is met, including deletion across all geographic instances. The bullet about pre-authorization SAD was a best practice until 31 March 2025 and is now mandatory.", "remediacion_en": "1) Identify all account data locations with Amazon Macie (automated discovery), Microsoft Purview (Storage/SQL scans) or GCP Sensitive Data Protection, including backups, snapshots, logs and multi-region replicas. 2) Document retention periods and justification per data type. 3) Automate deletion: S3 Lifecycle (Expiration and NoncurrentVersionExpiration), DynamoDB TTL, AWS Backup/RDS retention, Azure Blob lifecycle management, Cloud Storage Object Lifecycle, and bounded retention in CloudWatch Logs/Log Analytics/Cloud Logging for logs containing account data. 4) Use crypto-shredding (deleting a dedicated CMK) or services with secure deletion where overwrite is not possible. 5) Run and record a quarterly review confirming no data exceeds its retention period (signed Macie/Purview/DLP report). 6) Evidence: retention policy, lifecycle configurations and quarterly reports.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 81, "pagina_pdf_es": 88 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Amazon Macie habilitado con descubrimiento automatizado de datos sensibles [Macie.1] [Macie.2]", "Buckets S3 con hallazgos de Macie de tipo CREDIT_CARD_NUMBER sin regla de S3 Lifecycle Expiration (falla si existe)", "Tablas DynamoDB identificadas como repositorio de datos de cuenta sin TTL habilitado (falla si existe)", "Grupos de CloudWatch Logs del CDE con retentionInDays sin definir (retención indefinida) o mayor a la política", "RDS/AWS Backup: BackupRetentionPeriod y reglas de plan de respaldo coherentes con la política de retención" ], "checks_azure": [ "Microsoft Purview: data map con escaneos programados sobre Storage Accounts y Azure SQL del CDE", "Storage Accounts con datos de cuenta sin lifecycle management policy de eliminación (falla si existe)", "Log Analytics workspaces del CDE con retentionInDays acorde a la política", "Azure SQL: retención de respaldos PITR/LTR coherente con la política" ], "checks_gcp": [ "Sensitive Data Protection: discovery scan configurado para Cloud Storage/BigQuery/Cloud SQL del CDE", "Buckets de Cloud Storage con hallazgos CREDIT_CARD_NUMBER sin lifecycle rule Delete (falla si existe)", "BigQuery: tablas o particiones con datos de cuenta sin defaultTableExpirationMs/partitionExpirationMs", "Cloud Logging buckets del CDE con retentionDays acorde a la política" ], "evidencia": "Inventario generado de ubicaciones con datos de cuenta (Macie/Purview/DLP), configuraciones de ciclo de vida y retención, política de retención con justificación y registros de la revisión trimestral.", "evidencia_en": "Generated inventory of account data locations (Macie/Purview/DLP), lifecycle and retention configurations, retention policy with justification and quarterly review records.", "limitaciones": "El escaneo no prueba que la eliminación sea irrecuperable ni cubre datos en papel, endpoints o grabaciones fuera de la nube; la justificación de negocio es documental.", "limitaciones_en": "Scanning does not prove deletion is unrecoverable nor cover paper, endpoints or recordings outside the cloud; business justification is documentary.", "responsabilidad_compartida": "compartida", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.33", "8.10", "5.34" ], "soc2_tsc": [ "C1.1", "C1.2", "CC6.5" ], "cis_controls_v8": [ "3.1", "3.2", "3.4", "3.5" ], "banxico_spei": [ "58a. I.A.d).1" ] } }, { "id": 31, "numero_regla": "3.3.1", "requisito": "3", "seccion": "3.3", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Datos de autenticación sensibles (SAD) no almacenados tras la autorización", "seccion_titulo_en": "Sensitive authentication data (SAD) is not stored after authorization", "descripcion_corta": "SAD no se almacena después de la autorización, ni siquiera cifrado", "descripcion_larga": "Los datos de autenticación confidenciales (SAD) no deben conservarse una vez completada la autorización, aunque estén cifrados; todo SAD recibido debe volverse irrecuperable al terminar ese proceso. La autorización concluye cuando el comercio recibe la respuesta de la transacción (aprobación o rechazo). Los emisores y empresas que apoyan servicios de emisión con necesidad legítima y documentada quedan exentos y se rigen por el Requisito 3.3.3. Los SAD comprenden los datos de los Requisitos 3.3.1.1 a 3.3.1.3; no admite enfoque personalizado.", "remediacion": "1) Revise los flujos de datos de pago para confirmar que ningún componente persiste SAD (pista completa, código de verificación, PIN/bloque PIN) tras la respuesta de autorización. 2) Configure descubrimiento recurrente: Amazon Macie con identificadores CREDIT_CARD_MAGNETIC_STRIPE y CREDIT_CARD_SECURITY_CODE, Microsoft Purview con tipos de información confidencial personalizados y GCP Sensitive Data Protection (CREDIT_CARD_TRACK_NUMBER y detectores personalizados). 3) Escanee snapshots de discos, bases de datos, bitácoras de aplicación y depuración, y volcados de memoria. 4) Desactive el registro de cuerpos de petición en API Gateway, ALB, Application Gateway y balanceadores de GCP para endpoints de pago. 5) Elimine de forma segura cualquier hallazgo y documente la causa raíz. 6) Evidencia: diagramas de flujo de datos, configuraciones de logging y reportes de descubrimiento sin hallazgos de SAD.", "descripcion_corta_en": "SAD not stored after authorization, even if encrypted", "descripcion_larga_en": "Sensitive authentication data (SAD) must not be retained once authorization completes, even if it is encrypted; all SAD received must be rendered unrecoverable at the end of that process. Authorization completes when the merchant receives the transaction response (approval or decline). Issuers and companies supporting issuing services with a legitimate, documented business need are exempt and are governed by Requirement 3.3.3. SAD includes the data covered by Requirements 3.3.1.1 through 3.3.1.3; the customized approach is not allowed.", "remediacion_en": "1) Review payment data flows to confirm no component persists SAD (full track, card verification code, PIN/PIN block) after the authorization response. 2) Set up recurring discovery: Amazon Macie with CREDIT_CARD_MAGNETIC_STRIPE and CREDIT_CARD_SECURITY_CODE identifiers, Microsoft Purview with custom sensitive information types, and GCP Sensitive Data Protection (CREDIT_CARD_TRACK_NUMBER plus custom detectors). 3) Scan disk snapshots, databases, application and debug logs, and memory dumps. 4) Disable request body logging in API Gateway, ALB, Application Gateway and GCP load balancers for payment endpoints. 5) Securely delete any finding and document the root cause. 6) Evidence: data flow diagrams, logging configurations and discovery reports with no SAD findings.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 83, "pagina_pdf_es": 91 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Amazon Macie: hallazgos SensitiveData:S3Object/Financial con CREDIT_CARD_MAGNETIC_STRIPE o CREDIT_CARD_SECURITY_CODE (falla si existe)", "Escaneo de snapshots EBS y exportaciones de RDS en busca de patrones de pista 1/2 y CVV junto a PAN (falla si existe)", "API Gateway: access logs/execution logs con dataTraceEnabled = true en stages de pago (falla si existe)", "CloudWatch Logs del CDE: búsqueda de patrones de datos de pista en grupos de logs de aplicación" ], "checks_azure": [ "Microsoft Purview / Defender for Storage: clasificación de datos sensibles con SIT personalizado de datos de pista/CVV (falla si hay hallazgos)", "Escaneo de snapshots de Managed Disks en busca de patrones de pista y CVV (falla si existe)", "Application Insights/Log Analytics del CDE: búsqueda de patrones de datos de pista en cuerpos de petición registrados" ], "checks_gcp": [ "Sensitive Data Protection: hallazgos CREDIT_CARD_TRACK_NUMBER en Cloud Storage/BigQuery/Cloud SQL (falla si existe)", "Escaneo de snapshots de Persistent Disk en busca de patrones de pista y CVV (falla si existe)", "Cloud Logging del CDE: búsqueda de patrones de datos de pista en logs de aplicación y balanceadores" ], "evidencia": "Reportes de descubrimiento (Kyber, Macie, Purview, DLP) sin hallazgos de SAD, diagrama de flujo de autorización y procedimiento de borrado seguro.", "evidencia_en": "Discovery reports (Kyber, Macie, Purview, DLP) with no SAD findings, authorization flow diagram and secure deletion procedure.", "limitaciones": "La detección por patrones no identifica PIN ni bloques PIN cifrados, no cubre memoria volátil ni datos fuera de la nube, y la ausencia de hallazgos no prueba ausencia de SAD.", "limitaciones_en": "Pattern detection cannot identify PINs or encrypted PIN blocks, does not cover volatile memory or off-cloud data, and absence of findings does not prove absence of SAD.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.10", "8.11", "5.34" ], "soc2_tsc": [ "C1.1", "C1.2", "CC6.1" ], "cis_controls_v8": [ "3.1", "3.4", "3.7" ] } }, { "id": 32, "numero_regla": "3.3.1.1", "requisito": "3", "seccion": "3.3", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Datos de autenticación sensibles (SAD) no almacenados tras la autorización", "seccion_titulo_en": "Sensitive authentication data (SAD) is not stored after authorization", "descripcion_corta": "Contenido completo de la pista no se almacena tras la autorización", "descripcion_larga": "Una vez completada la autorización no debe conservarse el contenido completo de ninguna pista (banda magnética, su equivalente en el chip u otra fuente), también llamado datos de pista 1/2 o de banda magnética. Solo pueden retenerse, si el negocio lo requiere y protegidos, el nombre del titular, el PAN, la fecha de vencimiento y el código de servicio. Deben revisarse datos de transacciones entrantes, todas las bitácoras, archivos de historial y de rastreo, esquemas y contenido de bases de datos (locales y en la nube) y volcados de memoria. No admite enfoque personalizado.", "remediacion": "1) Asegure que las aplicaciones solo extraigan nombre, PAN, vencimiento y código de servicio de la pista y descarten el resto al recibir la respuesta. 2) Active detección recurrente: Macie con CREDIT_CARD_MAGNETIC_STRIPE, Sensitive Data Protection con CREDIT_CARD_TRACK_NUMBER y Purview con SIT personalizado (expresiones regulares de pista 1 '%B...^...?' y pista 2 ';...=...?'). 3) Incluya snapshots de discos, respaldos, bitácoras de depuración y error, y volcados de memoria/crash dumps. 4) Revise esquemas de bases de datos para detectar columnas destinadas a datos de pista. 5) Elimine hallazgos de forma segura y corrija la fuente. 6) Evidencia: reportes de escaneo sin hallazgos y revisión de esquemas.", "descripcion_corta_en": "Full track contents not stored after authorization", "descripcion_larga_en": "After authorization completes, the full contents of any track (magnetic stripe, equivalent chip data or elsewhere), also known as track 1/2 or magnetic-stripe data, must not be retained. Only cardholder name, PAN, expiration date and service code may be kept, if needed for business and stored securely. Sources to review include incoming transaction data, all logs, history and trace files, database schemas and contents (on-premises and cloud) and memory dumps. The customized approach is not allowed.", "remediacion_en": "1) Ensure applications only extract name, PAN, expiration and service code from the track and discard the rest when the response arrives. 2) Enable recurring detection: Macie with CREDIT_CARD_MAGNETIC_STRIPE, Sensitive Data Protection with CREDIT_CARD_TRACK_NUMBER and Purview with a custom SIT (track 1 '%B...^...?' and track 2 ';...=...?' regexes). 3) Include disk snapshots, backups, debug and error logs, and memory/crash dumps. 4) Review database schemas for columns meant to hold track data. 5) Securely delete findings and fix the source. 6) Evidence: scan reports with no findings and schema review.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 84, "pagina_pdf_es": 92 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Amazon Macie: hallazgos con identificador gestionado CREDIT_CARD_MAGNETIC_STRIPE en S3 (falla si existe)", "Escaneo de snapshots EBS/RDS con regex de pista 1 y pista 2 (falla si existe)", "CloudWatch Logs del CDE: consultas de Logs Insights con patrones de pista (falla si hay coincidencias)" ], "checks_azure": [ "Purview/Defender for Storage: SIT personalizado de datos de pista en Storage y Azure SQL (falla si hay hallazgos)", "Escaneo de snapshots de Managed Disks con regex de pista 1/2 (falla si existe)", "Log Analytics del CDE: consultas KQL con patrones de pista (falla si hay coincidencias)" ], "checks_gcp": [ "Sensitive Data Protection: infoType CREDIT_CARD_TRACK_NUMBER en Cloud Storage/BigQuery (falla si existe)", "Escaneo de snapshots de Persistent Disk con regex de pista 1/2 (falla si existe)", "Cloud Logging del CDE: filtros con patrones de pista (falla si hay coincidencias)" ], "evidencia": "Reportes de descubrimiento sin datos de pista en almacenamiento, bitácoras y snapshots; revisión de esquemas de bases de datos.", "evidencia_en": "Discovery reports showing no track data in storage, logs and snapshots; database schema review.", "limitaciones": "No cubre memoria volátil, terminales POI ni sistemas fuera de la nube; datos cifrados o codificados por la aplicación no se detectan por patrón.", "limitaciones_en": "Does not cover volatile memory, POI terminals or off-cloud systems; data encrypted or encoded by the application is not detectable by pattern.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.10", "8.11" ], "soc2_tsc": [ "C1.1", "CC6.1" ], "cis_controls_v8": [ "3.1", "3.4" ] } }, { "id": 33, "numero_regla": "3.3.1.2", "requisito": "3", "seccion": "3.3", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Datos de autenticación sensibles (SAD) no almacenados tras la autorización", "seccion_titulo_en": "Sensitive authentication data (SAD) is not stored after authorization", "descripcion_corta": "Código de verificación de la tarjeta no se almacena tras la autorización", "descripcion_larga": "El código de verificación de la tarjeta (los tres o cuatro dígitos impresos en el anverso o reverso, usados en transacciones sin tarjeta presente) no debe conservarse al completarse la autorización. Deben revisarse datos de transacciones entrantes, todas las bitácoras, archivos de historial y rastreo, esquemas y contenido de bases de datos en sitio y en la nube y volcados de memoria. Si el código se registra en papel antes de la autorización, debe hacerse ilegible después (por ejemplo, recortándolo o tachándolo con marcador opaco permanente). No admite enfoque personalizado.", "remediacion": "1) Verifique que el CVV/CVC solo se use en memoria para enviarlo al adquirente y nunca se escriba en bases de datos, colas (SQS, Service Bus, Pub/Sub) ni bitácoras. 2) Revise esquemas y modelos de datos para eliminar campos de CVV. 3) Configure detección: Macie con CREDIT_CARD_SECURITY_CODE, Purview y Sensitive Data Protection con detectores personalizados por palabra clave cercana a PAN. 4) Deshabilite el registro de cuerpos de petición en API Gateway, WAF logging con campos redactados (redactedFields), Application Gateway y Cloud Armor/Load Balancing. 5) Defina procedimiento para destruir o tachar el código en formatos en papel. 6) Evidencia: revisión de esquemas, configuración de redacción de logs y reportes de escaneo sin hallazgos.", "descripcion_corta_en": "Card verification code not stored after authorization", "descripcion_larga_en": "The card verification code (the three- or four-digit number printed on the front or back of the card, used for card-not-present transactions) must not be retained once authorization completes. Sources to review include incoming transaction data, all logs, history and trace files, database schemas and contents on-premises and in the cloud, and memory dumps. If the code is written on paper before authorization, it must be made unreadable afterward (for example by cutting it out or covering it with a permanent opaque marker). The customized approach is not allowed.", "remediacion_en": "1) Verify the CVV/CVC is only held in memory to forward to the acquirer and is never written to databases, queues (SQS, Service Bus, Pub/Sub) or logs. 2) Review schemas and data models to remove CVV fields. 3) Configure detection: Macie with CREDIT_CARD_SECURITY_CODE, Purview and Sensitive Data Protection with custom keyword-proximity detectors near PAN. 4) Disable request body logging in API Gateway, use WAF logging with redactedFields, and review Application Gateway and Cloud Armor/Load Balancing logging. 5) Define a procedure to destroy or black out the code on paper forms. 6) Evidence: schema review, log redaction configuration and scan reports with no findings.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 85, "pagina_pdf_es": 93 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Amazon Macie: hallazgos con CREDIT_CARD_SECURITY_CODE en S3 (falla si existe)", "AWS WAF: loggingConfiguration de web ACLs de pago sin redactedFields para cuerpo/campos de tarjeta (revisión)", "API Gateway: dataTraceEnabled = true en stages de endpoints de pago (falla si existe)", "Escaneo de snapshots EBS/RDS buscando campos cvv/cvc/cvv2 con valores de 3-4 dígitos junto a PAN (falla si existe)" ], "checks_azure": [ "Purview: SIT personalizado de código de verificación (palabra clave + 3-4 dígitos) en Storage/SQL (falla si hay hallazgos)", "Escaneo de snapshots de Managed Disks y esquemas Azure SQL buscando columnas cvv/cvc (falla si existe)", "API Management: diagnósticos con registro de cuerpo de petición en APIs de pago (falla si existe)" ], "checks_gcp": [ "Sensitive Data Protection: detector personalizado de código de verificación en Cloud Storage/BigQuery (falla si hay hallazgos)", "Escaneo de snapshots de Persistent Disk y esquemas Cloud SQL/BigQuery buscando columnas cvv/cvc (falla si existe)", "Apigee/API Gateway: políticas de logging que capturan cuerpos de petición de pago (revisión)" ], "evidencia": "Reportes de escaneo sin códigos de verificación, revisión de esquemas, configuración de redacción de bitácoras y procedimiento para papel.", "evidencia_en": "Scan reports with no verification codes, schema review, log redaction configuration and paper-handling procedure.", "limitaciones": "Un número de 3-4 dígitos sin contexto genera falsos positivos/negativos; no cubre papel, memoria ni sistemas fuera de la nube.", "limitaciones_en": "A context-free 3-4 digit number yields false positives/negatives; paper, memory and off-cloud systems are not covered.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.10", "8.11" ], "soc2_tsc": [ "C1.1", "CC6.1" ], "cis_controls_v8": [ "3.1", "3.4" ] } }, { "id": 34, "numero_regla": "3.3.1.3", "requisito": "3", "seccion": "3.3", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Datos de autenticación sensibles (SAD) no almacenados tras la autorización", "seccion_titulo_en": "Sensitive authentication data (SAD) is not stored after authorization", "descripcion_corta": "PIN y bloque PIN no se almacenan tras la autorización", "descripcion_larga": "El número de identificación personal (PIN) y el bloque PIN no deben conservarse una vez completada la autorización. Aunque el bloque PIN ya viaja cifrado durante la transacción, volver a cifrarlo no autoriza su almacenamiento posterior. Deben revisarse datos de transacciones entrantes, bitácoras, archivos de historial y rastreo, esquemas y contenido de bases de datos en sitio y en la nube y volcados de memoria. No admite enfoque personalizado.", "remediacion": "1) Confirme con el diseño de la solución y el proveedor de pagos que PIN y bloques PIN solo se procesan en dispositivos PTS/HSM de pago (p. ej. AWS Payment Cryptography, HSM dedicados) y nunca se persisten en aplicaciones. 2) Revise esquemas de bases de datos, colas y bitácoras para descartar campos de PIN/bloque PIN (p. ej. formatos ISO 9564). 3) Asegure que los mensajes ISO 8583 no se registren completos (campo 52) en CloudWatch, Log Analytics o Cloud Logging. 4) Incluya snapshots, respaldos y volcados de memoria en las revisiones. 5) Elimine de forma segura cualquier hallazgo. 6) Evidencia: diagrama de flujo de PIN, revisión de esquemas y configuración de logging.", "descripcion_corta_en": "PIN and PIN block not stored after authorization", "descripcion_larga_en": "The personal identification number (PIN) and PIN block must not be retained after authorization completes. Even though PIN blocks are already encrypted during the transaction, re-encrypting them does not allow them to be stored afterward. Sources to review include incoming transaction data, logs, history and trace files, database schemas and contents on-premises and in the cloud, and memory dumps. The customized approach is not allowed.", "remediacion_en": "1) Confirm with the solution design and payment provider that PINs and PIN blocks are only processed within PTS/payment HSM devices (e.g., AWS Payment Cryptography, dedicated HSMs) and never persisted by applications. 2) Review database schemas, queues and logs to rule out PIN/PIN block fields (e.g., ISO 9564 formats). 3) Ensure full ISO 8583 messages (field 52) are not logged to CloudWatch, Log Analytics or Cloud Logging. 4) Include snapshots, backups and memory dumps in reviews. 5) Securely delete any finding. 6) Evidence: PIN flow diagram, schema review and logging configuration.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 86, "pagina_pdf_es": 94 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "baja", "checks_aws": [ "Escaneo de esquemas RDS/Aurora/DynamoDB y snapshots EBS buscando columnas o atributos pin/pinblock/field52 (falla si existe)", "CloudWatch Logs del CDE: búsqueda de mensajes ISO 8583 con campo 52 registrado (falla si hay coincidencias)", "Inventario de uso de AWS Payment Cryptography/CloudHSM para operaciones de PIN (informativo)" ], "checks_azure": [ "Escaneo de esquemas Azure SQL/Cosmos DB y snapshots de Managed Disks buscando columnas pin/pinblock (falla si existe)", "Log Analytics del CDE: búsqueda de mensajes ISO 8583 con campo 52 (falla si hay coincidencias)" ], "checks_gcp": [ "Escaneo de esquemas Cloud SQL/BigQuery/Firestore y snapshots de Persistent Disk buscando columnas pin/pinblock (falla si existe)", "Cloud Logging del CDE: búsqueda de mensajes ISO 8583 con campo 52 (falla si hay coincidencias)" ], "evidencia": "Diagrama del flujo de PIN, revisión de esquemas y bitácoras, y hallazgos de escaneo de Kyber sin indicios de PIN almacenado.", "evidencia_en": "PIN flow diagram, schema and log review, and Kyber scan results with no indication of stored PIN.", "limitaciones": "Los bloques PIN son datos cifrados sin patrón reconocible; el escaneo solo detecta indicios por nombres de campo o formatos de mensaje.", "limitaciones_en": "PIN blocks are encrypted data with no recognizable pattern; scanning only detects indicators via field names or message formats.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.10", "8.11" ], "soc2_tsc": [ "C1.1", "CC6.1" ], "cis_controls_v8": [ "3.1", "3.4" ] } }, { "id": 35, "numero_regla": "3.3.2", "requisito": "3", "seccion": "3.3", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Datos de autenticación sensibles (SAD) no almacenados tras la autorización", "seccion_titulo_en": "Sensitive authentication data (SAD) is not stored after authorization", "descripcion_corta": "SAD almacenado electrónicamente antes de la autorización cifrado con criptografía robusta", "descripcion_larga": "Todo SAD que se almacene electrónicamente antes de completar la autorización debe cifrarse con criptografía robusta. Aplica a cualquier almacenamiento de SAD aunque no haya PAN en el entorno; si se permite o no guardarlo antes de la autorización lo determinan las marcas de pago y adquirentes, y además aplica el Requisito 3.2.1. Emisores y empresas de servicios de emisión con necesidad legítima se rigen por el 3.3.3, y el requisito no obliga a recifrar bloques PIN ya cifrados correctamente. Se recomienda usar una clave distinta de la que cifra el PAN. Fue mejor práctica hasta el 31 de marzo de 2025; no admite enfoque personalizado.", "remediacion": "1) Inventaríe dónde se guarda SAD antes de la autorización (colas SQS/Service Bus/Pub/Sub, caches ElastiCache/Azure Cache for Redis/Memorystore, tablas temporales). 2) Cifre a nivel de aplicación con AES-256 (p. ej. AWS Encryption SDK, Azure Key Vault + SDK, Tink con Cloud KMS) usando una CMK dedicada distinta de la del PAN. 3) Habilite además cifrado del servicio con CMK: SQS KmsMasterKeyId, ElastiCache at-rest y in-transit, Service Bus Premium con CMK, Pub/Sub con CMEK. 4) Configure expiración corta (TTL de mensajes y llaves de caché) y bórrelo al recibir la respuesta. 5) Documente la autorización de marca/adquirente para retener SAD. 6) Evidencia: inventario, diseño criptográfico y configuraciones de cifrado.", "descripcion_corta_en": "SAD stored electronically before authorization encrypted with strong cryptography", "descripcion_larga_en": "Any SAD stored electronically before authorization completes must be encrypted using strong cryptography. It applies to all SAD storage even if no PAN is present; whether pre-authorization storage is allowed at all is decided by payment brands and acquirers, and Requirement 3.2.1 also applies. Issuers and issuing-service companies with a legitimate need follow 3.3.3 instead, and the requirement does not mean properly encrypted PIN blocks must be encrypted again. Using a different key than the one protecting PAN is recommended. It was a best practice until 31 March 2025; the customized approach is not allowed.", "remediacion_en": "1) Inventory where SAD is held before authorization (SQS/Service Bus/Pub/Sub queues, ElastiCache/Azure Cache for Redis/Memorystore caches, temporary tables). 2) Encrypt at the application level with AES-256 (e.g., AWS Encryption SDK, Azure Key Vault + SDK, Tink with Cloud KMS) using a dedicated CMK separate from the PAN key. 3) Also enable service encryption with CMK: SQS KmsMasterKeyId, ElastiCache at-rest and in-transit, Service Bus Premium with CMK, Pub/Sub with CMEK. 4) Set short expiration (message TTL, cache key TTL) and delete it when the response arrives. 5) Document brand/acquirer authorization to hold SAD. 6) Evidence: inventory, cryptographic design and encryption configurations.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 87, "pagina_pdf_es": 95 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Colas SQS del flujo de pago sin KmsMasterKeyId de CMK (falla si existe)", "ElastiCache para Redis: AtRestEncryptionEnabled y TransitEncryptionEnabled = true en clústeres del CDE", "Tablas DynamoDB temporales de autorización con cifrado por CMK y TTL habilitado", "Escaneo de snapshots/almacenamiento: SAD en texto claro detectado por patrones (falla si existe)" ], "checks_azure": [ "Service Bus/Event Hubs del flujo de pago con cifrado por CMK de Key Vault (namespace encryption keySource = Microsoft.KeyVault)", "Azure Cache for Redis: enableNonSslPort = false y minimumTlsVersion = 1.2", "Escaneo de snapshots/almacenamiento: SAD en texto claro detectado por patrones (falla si existe)" ], "checks_gcp": [ "Pub/Sub: temas del flujo de pago con kmsKeyName (CMEK) configurado", "Memorystore for Redis: transitEncryptionMode = SERVER_AUTHENTICATION y CMEK en instancias del CDE", "Escaneo de snapshots/almacenamiento: SAD en texto claro detectado por patrones (falla si existe)" ], "evidencia": "Inventario de almacenamiento previo a la autorización, diseño de cifrado a nivel de aplicación, configuraciones de CMK y autorización de marca/adquirente.", "evidencia_en": "Inventory of pre-authorization storage, application-level encryption design, CMK configurations and brand/acquirer authorization.", "limitaciones": "El escaneo valida cifrado del servicio, no el cifrado a nivel de aplicación ni la robustez del algoritmo usado en el código.", "limitaciones_en": "Scanning validates service-side encryption, not application-level encryption or the strength of the algorithm used in code.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "8.10" ], "soc2_tsc": [ "CC6.1", "C1.1" ], "cis_controls_v8": [ "3.11", "3.4" ] } }, { "id": 36, "numero_regla": "3.3.3", "requisito": "3", "seccion": "3.3", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Datos de autenticación sensibles (SAD) no almacenados tras la autorización", "seccion_titulo_en": "Sensitive authentication data (SAD) is not stored after authorization", "descripcion_corta": "Emisores: almacenamiento de SAD limitado a necesidad legítima, protegido y cifrado", "descripcion_larga": "Requisito adicional exclusivo para emisores y empresas que apoyan servicios de emisión y almacenan SAD: cualquier almacenamiento de SAD debe limitarse a lo necesario para una necesidad legítima de negocio de emisión, estar protegido y cifrarse con criptografía robusta. Una necesidad legítima es aquella indispensable para la función que se presta para o por el emisor. El punto de cifrado con criptografía robusta fue mejor práctica hasta el 31 de marzo de 2025 y ahora es obligatorio.", "remediacion": "1) Documente la justificación de negocio de emisión para cada tipo de SAD almacenado y su ubicación. 2) Cifre el SAD a nivel de aplicación o campo con llaves en HSM (AWS CloudHSM o Payment Cryptography, Azure Managed HSM/Dedicated HSM, Cloud HSM) separadas de las del PAN. 3) Restrinja el acceso a los repositorios con IAM/RBAC de privilegio mínimo y red privada (VPC endpoints, Private Endpoints, Private Service Connect). 4) Habilite cifrado del servicio con CMK y auditoría de accesos (CloudTrail data events, diagnósticos de Azure, Data Access audit logs). 5) Revise periódicamente que el volumen almacenado no exceda la necesidad documentada. 6) Evidencia: justificación, diseño criptográfico y configuraciones de acceso.", "descripcion_corta_en": "Issuers: SAD storage limited to legitimate need, secured and encrypted", "descripcion_larga_en": "Additional requirement only for issuers and companies supporting issuing services that store SAD: any SAD storage must be limited to what a legitimate issuing business need requires, be secured, and be encrypted with strong cryptography. A legitimate issuing need is one necessary for the function performed by or for the issuer. The strong-cryptography bullet was a best practice until 31 March 2025 and is now mandatory.", "remediacion_en": "1) Document the issuing business justification for each SAD type stored and its location. 2) Encrypt SAD at the application or field level with HSM-backed keys (AWS CloudHSM or Payment Cryptography, Azure Managed HSM/Dedicated HSM, Cloud HSM) separate from PAN keys. 3) Restrict repository access with least-privilege IAM/RBAC and private networking (VPC endpoints, Private Endpoints, Private Service Connect). 4) Enable CMK service encryption and access auditing (CloudTrail data events, Azure diagnostics, Data Access audit logs). 5) Periodically review that stored volume does not exceed the documented need. 6) Evidence: justification, cryptographic design and access configurations.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 89, "pagina_pdf_es": 97 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [ "Repositorios de SAD (S3/RDS/DynamoDB) con cifrado por CMK y sin acceso público [S3.17] [RDS.3]", "CloudTrail data events habilitados para buckets/tablas que contienen SAD", "Llaves usadas para SAD distintas de las usadas para PAN (comparación de KeyId por recurso)" ], "checks_azure": [ "Repositorios de SAD (Storage/SQL/Cosmos DB) con CMK en Key Vault o Managed HSM y publicNetworkAccess = Disabled", "Diagnostic settings habilitados en los repositorios de SAD hacia Log Analytics" ], "checks_gcp": [ "Repositorios de SAD (Cloud Storage/Cloud SQL/BigQuery) con CMEK en Cloud KMS de protectionLevel HSM", "Data Access audit logs habilitados para los servicios que almacenan SAD" ], "evidencia": "Justificación de negocio de emisión documentada, diseño criptográfico y configuraciones de cifrado y acceso de los repositorios.", "evidencia_en": "Documented issuing business justification, cryptographic design and repository encryption and access configurations.", "limitaciones": "Aplica solo a emisores; Kyber no puede validar la legitimidad de la necesidad de negocio ni el cifrado a nivel de aplicación.", "limitaciones_en": "Applies only to issuers; Kyber cannot validate the legitimacy of the business need or application-level encryption.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "8.10", "8.3" ], "soc2_tsc": [ "CC6.1", "C1.1" ], "cis_controls_v8": [ "3.11", "3.3" ] } }, { "id": 37, "numero_regla": "3.4.1", "requisito": "3", "seccion": "3.4", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Visualización y copia del PAN completo restringidas", "seccion_titulo_en": "Access to displays of full PAN and ability to copy PAN are restricted", "descripcion_corta": "PAN enmascarado al mostrarse (máximo BIN y últimos cuatro dígitos)", "descripcion_larga": "Cuando se muestra el PAN debe enmascararse de modo que, como máximo, se vean el BIN y los últimos cuatro dígitos, y solo el personal con necesidad legítima de negocio pueda ver más. Debe existir una lista documentada de roles con acceso a más dígitos y su justificación; todos los demás solo ven el PAN enmascarado. Enmascarar no equivale a truncar: el enmascaramiento oculta dígitos al mostrar o imprimir aunque el PAN completo siga almacenado. No sustituye requisitos más estrictos (legales o de marcas, p. ej. recibos POS) y es distinto de la protección del PAN almacenado del Requisito 3.5.1.", "remediacion": "1) Documente los roles que necesitan ver más que BIN + últimos cuatro, con su justificación. 2) Implemente el enmascaramiento en la capa de aplicación y API, mostrando solo los dígitos mínimos necesarios por función. 3) Use enmascaramiento dinámico en bases de datos y analítica: Azure SQL Dynamic Data Masking, BigQuery data masking con policy tags, Amazon Redshift dynamic data masking o AWS Lake Formation con filtros de columnas. 4) Asigne el permiso de desenmascarar (p. ej. UNMASK en Azure SQL, Masked Reader/Fine-Grained Reader en BigQuery) solo a los roles documentados. 5) Revise pantallas, reportes y recibos. 6) Evidencia: lista de roles, configuración de enmascaramiento y capturas de pantalla.", "descripcion_corta_en": "PAN masked when displayed (maximum BIN and last four digits)", "descripcion_larga_en": "When PAN is displayed it must be masked so that at most the BIN and last four digits are visible, and only personnel with a legitimate business need can see more. A documented list of roles with access to more digits and their justification must exist; all other roles see only masked PAN. Masking is not truncation: masking hides digits on display or print even though the full PAN remains stored. It does not replace stricter legal or brand rules (e.g., POS receipts) and is distinct from protection of stored PAN under Requirement 3.5.1.", "remediacion_en": "1) Document roles that need to see more than BIN + last four, with justification. 2) Implement masking in the application and API layers, showing only the minimum digits per function. 3) Use dynamic masking in databases and analytics: Azure SQL Dynamic Data Masking, BigQuery data masking with policy tags, Amazon Redshift dynamic data masking or AWS Lake Formation column filters. 4) Grant unmask permissions (e.g., UNMASK in Azure SQL, Masked Reader/Fine-Grained Reader in BigQuery) only to documented roles. 5) Review screens, reports and receipts. 6) Evidence: role list, masking configuration and screenshots.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 91, "pagina_pdf_es": 99 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [ "Amazon Redshift: políticas de dynamic data masking adjuntas a columnas de PAN (revisión)", "AWS Lake Formation: permisos de columna/filtros de datos que excluyen PAN completo para roles no autorizados" ], "checks_azure": [ "Azure SQL: dataMaskingPolicies/dataMaskingRules activas sobre columnas de PAN (falla si la columna con PAN no tiene regla)", "Azure SQL: principales con permiso UNMASK limitados a la lista de roles documentada" ], "checks_gcp": [ "BigQuery: policy tags con data masking rules en columnas de PAN (falla si la columna con PAN no tiene política)", "BigQuery: miembros con roles/bigquerydatapolicy.maskedReader o datacatalog.categoryFineGrainedReader limitados a roles documentados" ], "evidencia": "Lista de roles autorizados con justificación, configuración de enmascaramiento en aplicación/BD y capturas de pantallas y reportes.", "evidencia_en": "List of authorized roles with justification, masking configuration in application/DB and screenshots of displays and reports.", "limitaciones": "El enmascaramiento en pantallas de aplicación, recibos y reportes impresos no es visible para un escaneo de configuración de nube.", "limitaciones_en": "Masking in application screens, receipts and printed reports is not visible to a cloud configuration scan.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.11", "8.3" ], "soc2_tsc": [ "CC6.1", "C1.1" ], "cis_controls_v8": [ "3.3" ] } }, { "id": 38, "numero_regla": "3.4.2", "requisito": "3", "seccion": "3.4", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Visualización y copia del PAN completo restringidas", "seccion_titulo_en": "Access to displays of full PAN and ability to copy PAN are restricted", "descripcion_corta": "Controles técnicos impiden copiar o reubicar PAN en tecnologías de acceso remoto", "descripcion_larga": "Al usar tecnologías de acceso remoto (por ejemplo, escritorios virtuales), controles técnicos deben impedir que cualquier persona copie o reubique el PAN, salvo quienes tengan autorización explícita documentada y una necesidad de negocio legítima y definida. Debe mantenerse la lista de personas autorizadas con su justificación. Los dispositivos de almacenamiento incluyen discos locales y virtuales, medios removibles, unidades de red y almacenamiento en la nube; guardar PAN en ellos los incorpora al alcance de PCI DSS. Fue mejor práctica hasta el 31 de marzo de 2025.", "remediacion": "1) Identifique todas las vías de acceso remoto a sistemas con PAN (Amazon WorkSpaces/AppStream 2.0, Azure Virtual Desktop, Azure Bastion, VDI de terceros en Compute Engine, Session Manager). 2) Deshabilite portapapeles, redirección de unidades, USB e impresión: AppStream 2.0 UserSettings (CLIPBOARD_COPY_FROM_LOCAL_DEVICE, CLIPBOARD_COPY_TO_LOCAL_DEVICE, FILE_DOWNLOAD, PRINTING_TO_LOCAL_DEVICE = DISABLED), AVD customRdpProperty (redirectclipboard:i:0; drivestoredirect:s:; usbdevicestoredirect:s:), Azure Bastion disableCopyPaste = true. 3) Cree excepciones solo para grupos autorizados con un pool/stack separado. 4) Mantenga la lista de personas autorizadas con su justificación y revísela periódicamente. 5) Evidencia: configuraciones de las herramientas de acceso remoto, lista de excepciones y prueba de que la copia está bloqueada.", "descripcion_corta_en": "Technical controls prevent copying or relocating PAN via remote-access technologies", "descripcion_larga_en": "When remote-access technologies (e.g., virtual desktops) are used, technical controls must prevent everyone from copying or relocating PAN, except those with documented, explicit authorization and a legitimate, defined business need. A list of authorized personnel with their justification must be maintained. Storage devices include local and virtual drives, removable media, network drives and cloud storage; placing PAN on them brings them into PCI DSS scope. It was a best practice until 31 March 2025.", "remediacion_en": "1) Identify all remote-access paths to systems with PAN (Amazon WorkSpaces/AppStream 2.0, Azure Virtual Desktop, Azure Bastion, third-party VDI on Compute Engine, Session Manager). 2) Disable clipboard, drive redirection, USB and printing: AppStream 2.0 UserSettings (CLIPBOARD_COPY_FROM_LOCAL_DEVICE, CLIPBOARD_COPY_TO_LOCAL_DEVICE, FILE_DOWNLOAD, PRINTING_TO_LOCAL_DEVICE = DISABLED), AVD customRdpProperty (redirectclipboard:i:0; drivestoredirect:s:; usbdevicestoredirect:s:), Azure Bastion disableCopyPaste = true. 3) Create exceptions only for authorized groups through a separate pool/stack. 4) Maintain and periodically review the list of authorized people with justification. 5) Evidence: remote-access tool configurations, exception list and proof that copying is blocked.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 93, "pagina_pdf_es": 101 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "AppStream 2.0 stacks del CDE con UserSettings CLIPBOARD_COPY_TO_LOCAL_DEVICE, FILE_DOWNLOAD o PRINTING_TO_LOCAL_DEVICE = ENABLED (falla si existe sin excepción documentada)", "Amazon WorkSpaces del CDE: inventario de directorios y políticas de DCV/PCoIP para redirección de portapapeles y unidades (revisión)", "SSM Session Manager: preferencias de sesión (SSM-SessionManagerRunShell) con s3BucketName/cloudWatchLogGroupName para auditoría de sesiones" ], "checks_azure": [ "Azure Virtual Desktop: host pools del CDE sin redirectclipboard:i:0 y drivestoredirect:s: en customRdpProperty (falla si existe)", "Azure Bastion: disableCopyPaste = false o enableFileCopy = true en hosts que acceden al CDE (falla si existe sin excepción)" ], "checks_gcp": [ "Compute Engine: inventario de instancias VDI/jump host del CDE e IAP TCP forwarding habilitado (revisión de controles de copia del producto de terceros)" ], "evidencia": "Configuraciones de AppStream/WorkSpaces/AVD/Bastion, lista de personal autorizado con justificación y prueba de bloqueo de copia.", "evidencia_en": "AppStream/WorkSpaces/AVD/Bastion configurations, list of authorized personnel with justification and proof that copying is blocked.", "limitaciones": "No cubre VDI de terceros (Citrix, VMware Horizon), políticas GPO dentro del sistema operativo ni GCP sin VDI nativo.", "limitaciones_en": "Does not cover third-party VDI (Citrix, VMware Horizon), in-OS GPO settings, or GCP which lacks native VDI.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.12", "8.3", "7.10" ], "soc2_tsc": [ "CC6.7", "CC6.1" ], "cis_controls_v8": [ "3.13", "3.3" ] } }, { "id": 39, "numero_regla": "3.5.1", "requisito": "3", "seccion": "3.5", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "PAN protegido dondequiera que se almacene", "seccion_titulo_en": "PAN is secured wherever it is stored", "descripcion_corta": "PAN ilegible en cualquier lugar donde se almacene", "descripcion_larga": "El PAN debe hacerse ilegible en todo lugar donde se almacene mediante alguno de estos enfoques: hash unidireccional con criptografía robusta de todo el PAN; truncamiento (sin usar hash para reemplazar el segmento truncado), con controles adicionales que impidan correlacionar versiones con hash y truncadas o distintos formatos de truncamiento para reconstruir el PAN; tokens de índice; o criptografía robusta con procesos y procedimientos de gestión de claves. Aplica tanto al almacenamiento primario (bases de datos, archivos planos, hojas de cálculo) como al no primario (respaldos, bitácoras de auditoría, de excepciones o de diagnóstico). Se permiten archivos temporales con PAN en claro durante el cifrado/descifrado.", "remediacion": "1) Descubra todo PAN almacenado con Amazon Macie, Microsoft Purview y GCP Sensitive Data Protection, más escaneo de snapshots de discos y bases de datos. 2) Aplique protección a nivel de campo o aplicación: tokenización, cifrado de columnas (AWS Encryption SDK o DynamoDB client-side encryption con KMS, Azure SQL Always Encrypted con llaves en Key Vault, Tink con Cloud KMS) o truncamiento. 3) Use además cifrado del servicio con CMK: S3 SSE-KMS [S3.17], RDS/Aurora cifrado [RDS.3], EBS por defecto [EC2.7], Azure Storage/SQL TDE con CMK, GCP CMEK; recuerde que el cifrado de disco/almacenamiento por sí solo no basta (ver 3.5.1.2). 4) Si coexisten hash y truncamiento del mismo PAN, use hash con clave (HMAC) para impedir correlación. 5) Elimine PAN en claro de bitácoras. 6) Evidencia: documentación del método, configuraciones de cifrado y reportes de escaneo sin PAN en claro.", "descripcion_corta_en": "PAN rendered unreadable anywhere it is stored", "descripcion_larga_en": "PAN must be rendered unreadable wherever it is stored using one of these approaches: one-way hashes of the entire PAN based on strong cryptography; truncation (hashing cannot replace the truncated segment), with additional controls preventing hashed and truncated versions or different truncation formats of the same PAN from being correlated to rebuild it; index tokens; or strong cryptography with key-management processes and procedures. It applies to primary storage (databases, flat files, spreadsheets) and non-primary storage (backups, audit, exception or troubleshooting logs). Temporary files with cleartext PAN are allowed while encrypting/decrypting.", "remediacion_en": "1) Discover all stored PAN with Amazon Macie, Microsoft Purview and GCP Sensitive Data Protection, plus disk snapshot and database scanning. 2) Apply field- or application-level protection: tokenization, column encryption (AWS Encryption SDK or DynamoDB client-side encryption with KMS, Azure SQL Always Encrypted with Key Vault keys, Tink with Cloud KMS) or truncation. 3) Also use CMK service encryption: S3 SSE-KMS [S3.17], encrypted RDS/Aurora [RDS.3], EBS default encryption [EC2.7], Azure Storage/SQL TDE with CMK, GCP CMEK; storage or disk encryption alone is not enough (see 3.5.1.2). 4) If hashed and truncated forms of the same PAN coexist, use keyed hashing (HMAC) to prevent correlation. 5) Remove cleartext PAN from logs. 6) Evidence: method documentation, encryption configurations and scan reports with no cleartext PAN.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 94, "pagina_pdf_es": 102 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Amazon Macie: hallazgos CREDIT_CARD_NUMBER en S3, incluidos buckets de logs y respaldos (falla si existe)", "Buckets S3 con datos de cuenta sin SSE-KMS con CMK [S3.17]", "RDS/Aurora sin StorageEncrypted [RDS.3] o snapshots sin cifrar [RDS.4]; EBS sin cifrado por defecto [EC2.7]", "DynamoDB con datos de cuenta usando llave AWS owned en lugar de CMK (SSEDescription.SSEType != KMS)", "Escaneo de snapshots EBS/RDS buscando PAN válido por Luhn en texto claro (falla si existe)" ], "checks_azure": [ "Purview: clasificación Credit Card Number en Storage/Azure SQL/Cosmos DB (falla si hay PAN en claro)", "Storage Accounts con datos de cuenta sin encryption.keySource = Microsoft.Keyvault", "Azure SQL: TDE habilitado con protector en Key Vault y Always Encrypted en columnas de PAN (revisión)", "Escaneo de snapshots de Managed Disks buscando PAN en texto claro (falla si existe)" ], "checks_gcp": [ "Sensitive Data Protection: hallazgos CREDIT_CARD_NUMBER en Cloud Storage/BigQuery/Cloud SQL (falla si existe)", "Buckets, datasets de BigQuery e instancias Cloud SQL con datos de cuenta sin CMEK (kmsKeyName vacío)", "Escaneo de snapshots de Persistent Disk buscando PAN en texto claro (falla si existe)" ], "evidencia": "Reportes de descubrimiento de PAN, configuraciones de cifrado por recurso, documentación del método (tokenización/cifrado de campo/truncamiento) y algoritmos usados.", "evidencia_en": "PAN discovery reports, per-resource encryption configurations, method documentation (tokenization/field encryption/truncation) and algorithms used.", "limitaciones": "Kyber no puede confirmar tokenización o cifrado a nivel de aplicación más allá de no encontrar PAN en claro; el cifrado del servicio en nube equivale a cifrado transparente y por sí solo no satisface el requisito.", "limitaciones_en": "Kyber cannot confirm application-level tokenization or encryption beyond finding no cleartext PAN; cloud service encryption is transparent and alone does not satisfy the requirement.", "responsabilidad_compartida": "compartida", "capacidades_pendientes": [ "deteccion_pan_en_snapshots" ], "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "8.11" ], "soc2_tsc": [ "CC6.1", "C1.1" ], "cis_controls_v8": [ "3.11" ], "banxico_spei": [ "58a. I.A.d).5", "58a. I.C.b)" ] }, "mapeo_ucf": [ { "clave": "UCF-CRY-001", "relacion": "partial", "cobertura_pct": 70, "nota_es": "PCI habla específicamente del PAN.", "nota_en": "PCI specifically addresses PAN." } ] }, { "id": 40, "numero_regla": "3.5.1.1", "requisito": "3", "seccion": "3.5", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "PAN protegido dondequiera que se almacene", "seccion_titulo_en": "PAN is secured wherever it is stored", "descripcion_corta": "Hashes del PAN son hashes criptográficos con clave y gestión de claves (3.6 y 3.7)", "descripcion_larga": "Cuando se usa hash para hacer ilegible el PAN (primer enfoque del Requisito 3.5.1), debe tratarse de un hash criptográfico con clave de todo el PAN, con procesos de gestión de claves conforme a los Requisitos 3.6 y 3.7. No se exige esa gestión de claves a componentes que solo generan hashes individuales para comparar con otro sistema si únicamente tienen acceso a un valor hash a la vez (sin almacenarlos) y no guardan otros datos de cuenta; el sistema central que sí acumula hashes sí debe cumplirla. Aplican también las notas del 3.5.1. Fue mejor práctica hasta el 31 de marzo de 2025 y sustituye la viñeta de hash unidireccional del 3.5.1.", "remediacion": "1) Sustituya hashes simples (SHA-256 del PAN, con o sin sal estática) por HMAC con clave secreta: AWS KMS HMAC keys (KeySpec HMAC_256, operación GenerateMac), Cloud KMS con propósito MAC (HMAC_SHA256) o una clave HMAC protegida en Azure Key Vault/Managed HSM. 2) Recalcule los hashes existentes y elimine los antiguos. 3) Aplique a las llaves HMAC los controles de 3.6 y 3.7: privilegio mínimo, rotación y custodios. 4) Documente qué sistemas solo manejan un hash a la vez para aplicar la exclusión. 5) Evidencia: documentación del método de hash, configuración de llaves y revisión de repositorios y bitácoras.", "descripcion_corta_en": "PAN hashes are keyed cryptographic hashes with key management (3.6 and 3.7)", "descripcion_larga_en": "When hashing is used to render PAN unreadable (first approach in Requirement 3.5.1), it must be a keyed cryptographic hash of the entire PAN, with key-management processes per Requirements 3.6 and 3.7. Such key management is not required for components that only generate individual hashes for comparison with another system if they access just one hash value at a time (not storing them) and hold no other account data; the backend that accumulates hashes must comply. Requirement 3.5.1 applicability notes also apply. It was a best practice until 31 March 2025 and replaces the one-way hash bullet of 3.5.1.", "remediacion_en": "1) Replace plain hashes (SHA-256 of PAN, with or without static salt) with secret-key HMAC: AWS KMS HMAC keys (KeySpec HMAC_256, GenerateMac), Cloud KMS MAC purpose keys (HMAC_SHA256) or an HMAC key protected in Azure Key Vault/Managed HSM. 2) Recompute existing hashes and delete old ones. 3) Apply 3.6 and 3.7 controls to HMAC keys: least privilege, rotation and custodians. 4) Document which systems only handle one hash at a time to apply the exclusion. 5) Evidence: hash method documentation, key configuration and review of repositories and logs.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 95, "pagina_pdf_es": 104 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [ "AWS KMS: existencia de llaves KeySpec HMAC_256/HMAC_512 con KeyUsage GENERATE_VERIFY_MAC para el hash del PAN (informativo)", "Políticas de llave HMAC sin Principal \"*\" y con kms:GenerateMac limitado a roles de aplicación [KMS.5]", "CloudTrail: uso de GenerateMac por la aplicación de pagos (evidencia de uso)" ], "checks_azure": [ "Key Vault/Managed HSM: llave o secreto designado para HMAC con acceso RBAC limitado a la identidad administrada de la aplicación" ], "checks_gcp": [ "Cloud KMS: CryptoKeys con purpose MAC y algoritmo HMAC_SHA256 para el hash del PAN (informativo)", "IAM de la llave MAC sin allUsers/allAuthenticatedUsers y roles/cloudkms.signerVerifier limitado a la cuenta de servicio de la aplicación" ], "evidencia": "Documentación del algoritmo de hash con clave, configuración de llaves HMAC y procedimientos de gestión de claves aplicables.", "evidencia_en": "Documentation of the keyed hash algorithm, HMAC key configuration and applicable key-management procedures.", "limitaciones": "Kyber no puede inspeccionar el código para confirmar que el hash se calcula con clave sobre todo el PAN.", "limitaciones_en": "Kyber cannot inspect code to confirm the hash is keyed and computed over the entire PAN.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "8.11" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "3.11" ] } }, { "id": 41, "numero_regla": "3.5.1.2", "requisito": "3", "seccion": "3.5", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "PAN protegido dondequiera que se almacene", "seccion_titulo_en": "PAN is secured wherever it is stored", "descripcion_corta": "Cifrado de disco o partición solo en medios removibles o junto con otro mecanismo", "descripcion_larga": "Si se usa cifrado a nivel de disco o partición (en lugar de cifrado de archivo, columna o campo) para hacer ilegible el PAN, solo es válido en medios electrónicos removibles; en medios no removibles el PAN debe además protegerse con otro mecanismo que cumpla el 3.5.1 (p. ej. truncamiento o cifrado a nivel de datos). Aplica a cualquier método que entregue el PAN en claro automáticamente al ejecutarse el sistema; los medios de un centro de datos (discos intercambiables en caliente, respaldos en cinta) se consideran no removibles. Estas implementaciones deben cumplir también los demás requisitos de cifrado y gestión de claves. Para emisores no aplica al PAN en procesamiento en tiempo real. Fue mejor práctica hasta el 31 de marzo de 2025.", "remediacion": "1) Identifique los volúmenes y almacenamientos que contienen PAN y solo están protegidos por cifrado transparente: EBS, RDS storage encryption, Azure Disk/Storage Service Encryption, SQL TDE, GCP Persistent Disk y Cloud SQL con CMEK. 2) Trate ese cifrado como capa base y agregue un mecanismo del 3.5.1 (tokenización, cifrado de campo, Always Encrypted, truncamiento). 3) Para medios removibles (p. ej. AWS Snowball, Azure Data Box, Transfer Appliance o respaldos exportados) asegure cifrado completo con llaves gestionadas. 4) Documente el diseño de capas de cifrado por repositorio. 5) Evidencia: matriz de repositorios con PAN y su mecanismo adicional, configuraciones y documentación del proveedor.", "descripcion_corta_en": "Disk or partition encryption only for removable media or alongside another mechanism", "descripcion_larga_en": "If disk-level or partition-level encryption (rather than file, column or field encryption) is used to render PAN unreadable, it is valid only on removable electronic media; on non-removable media PAN must also be protected by another mechanism meeting 3.5.1 (e.g., truncation or data-level encryption). It applies to any method that automatically yields cleartext PAN when the system runs; data center media (hot-swappable drives, bulk tape backups) count as non-removable. Such implementations must also meet all other encryption and key-management requirements. For issuers it does not apply to PAN used in real-time transaction processing. It was a best practice until 31 March 2025.", "remediacion_en": "1) Identify volumes and stores holding PAN that are protected only by transparent encryption: EBS, RDS storage encryption, Azure Disk/Storage Service Encryption, SQL TDE, GCP Persistent Disk and Cloud SQL with CMEK. 2) Treat that encryption as a baseline layer and add a 3.5.1 mechanism (tokenization, field encryption, Always Encrypted, truncation). 3) For removable media (e.g., AWS Snowball, Azure Data Box, Transfer Appliance or exported backups) ensure full encryption with managed keys. 4) Document the encryption layering per repository. 5) Evidence: matrix of PAN repositories and their additional mechanism, configurations and vendor documentation.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 97, "pagina_pdf_es": 106 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Volúmenes EBS/snapshots con PAN en claro detectado por escaneo y solo cifrado EBS (falla: falta mecanismo adicional del 3.5.1)", "RDS/Aurora con PAN detectado en exportaciones/snapshots y únicamente StorageEncrypted (falla sin evidencia de cifrado de campo/tokenización)", "Volúmenes EBS adjuntos sin cifrar [EC2.3] (falla: ni siquiera cifrado base)" ], "checks_azure": [ "Managed Disks con PAN en claro detectado por escaneo y solo SSE/ADE (falla: falta mecanismo adicional)", "Azure SQL con PAN en claro y solo TDE, sin Always Encrypted en columnas de PAN (falla)" ], "checks_gcp": [ "Persistent Disks con PAN en claro detectado por escaneo y solo cifrado por defecto o CMEK (falla: falta mecanismo adicional)", "Cloud SQL/BigQuery con PAN en claro y solo cifrado de almacenamiento (falla)" ], "evidencia": "Matriz de repositorios con PAN y mecanismo complementario, configuraciones de cifrado y hallazgos de escaneo de snapshots de Kyber.", "evidencia_en": "Matrix of PAN repositories and complementary mechanism, encryption configurations and Kyber snapshot scan findings.", "limitaciones": "Kyber detecta PAN legible en snapshots, pero no puede validar mecanismos de aplicación ni clasificar medios removibles fuera de la nube.", "limitaciones_en": "Kyber detects readable PAN in snapshots but cannot validate application mechanisms or classify removable media outside the cloud.", "responsabilidad_compartida": "compartida", "capacidades_pendientes": [ "deteccion_pan_en_snapshots" ], "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "7.10" ], "soc2_tsc": [ "CC6.1", "CC6.7" ], "cis_controls_v8": [ "3.11", "3.9" ] } }, { "id": 42, "numero_regla": "3.5.1.3", "requisito": "3", "seccion": "3.5", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "PAN protegido dondequiera que se almacene", "seccion_titulo_en": "PAN is secured wherever it is stored", "descripcion_corta": "Cifrado de disco: acceso lógico independiente del SO y llaves no asociadas a cuentas", "descripcion_larga": "Si se usa cifrado a nivel de disco o partición para hacer ilegible el PAN, debe gestionarse así: el acceso lógico se administra de forma separada e independiente de los mecanismos nativos de autenticación y control de acceso del sistema operativo; las llaves de descifrado no se asocian a cuentas de usuario; y los factores de autenticación (contraseñas, frases o llaves) que permiten acceder a los datos sin cifrar se almacenan de forma segura. Estas implementaciones también deben cumplir los demás requisitos de cifrado y gestión de claves.", "remediacion": "1) Use cifrado de volumen gestionado por el servicio con CMK (EBS con KMS, Azure Disk Encryption/Disk Encryption Sets con Key Vault, GCP CMEK) donde el descifrado lo realiza el hipervisor con permisos del servicio y no de cuentas del SO. 2) En la política de la CMK de volúmenes, conceda kms:Decrypt/CreateGrant solo vía el servicio (condición kms:ViaService = ec2..amazonaws.com) y no a usuarios humanos; en GCP otorgue cryptoKeyEncrypterDecrypter solo al agente de servicio de Compute Engine. 3) Para cifrado dentro del SO (BitLocker, LUKS) guarde las claves de recuperación en Key Vault/Secrets Manager/Secret Manager con acceso restringido, no en el propio host. 4) Habilite purge protection y registros de acceso a las llaves. 5) Evidencia: políticas de llave, configuración del cifrado y ubicación de factores de autenticación.", "descripcion_corta_en": "Disk encryption: logical access independent of OS and keys not tied to accounts", "descripcion_larga_en": "If disk- or partition-level encryption is used to render PAN unreadable, it must be managed as follows: logical access is managed separately and independently of native operating system authentication and access control; decryption keys are not associated with user accounts; and authentication factors (passwords, passphrases or keys) granting access to unencrypted data are stored securely. These implementations must also meet all other encryption and key-management requirements.", "remediacion_en": "1) Use service-managed volume encryption with a CMK (EBS with KMS, Azure Disk Encryption/Disk Encryption Sets with Key Vault, GCP CMEK) where decryption is performed by the hypervisor under service permissions, not OS accounts. 2) In the volume CMK policy, grant kms:Decrypt/CreateGrant only through the service (kms:ViaService = ec2..amazonaws.com) and not to human users; in GCP grant cryptoKeyEncrypterDecrypter only to the Compute Engine service agent. 3) For in-OS encryption (BitLocker, LUKS) store recovery keys in Key Vault/Secrets Manager/Secret Manager with restricted access, not on the host. 4) Enable purge protection and key access logging. 5) Evidence: key policies, encryption configuration and location of authentication factors.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 99, "pagina_pdf_es": 108 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Políticas de CMK usadas por EBS con kms:Decrypt a usuarios IAM o Principal \"*\" sin condición kms:ViaService (falla si existe) [KMS.5]", "Políticas IAM que permiten kms:Decrypt sobre todas las llaves [KMS.1] [KMS.2]", "Secretos de recuperación de cifrado en Secrets Manager con política de recurso restringida" ], "checks_azure": [ "Disk Encryption Sets con Key Vault: vault con enablePurgeProtection = true y acceso RBAC limitado a la identidad del DES", "Claves de recuperación de BitLocker/ADE almacenadas en Key Vault (no en el host) con acceso restringido" ], "checks_gcp": [ "Llaves CMEK de discos: IAM con roles/cloudkms.cryptoKeyEncrypterDecrypter solo para el agente de servicio de Compute Engine (falla si hay usuarios humanos)", "Llaves KMS sin allUsers/allAuthenticatedUsers (CIS GCP 1.9)" ], "evidencia": "Políticas de llave/IAM de volúmenes cifrados, configuración de cifrado de disco y ubicación protegida de claves de recuperación.", "evidencia_en": "Key/IAM policies for encrypted volumes, disk encryption configuration and protected location of recovery keys.", "limitaciones": "No puede evaluar cifrado dentro del SO (BitLocker/LUKS) ni cómo se custodian factores fuera de la nube.", "limitaciones_en": "Cannot evaluate in-OS encryption (BitLocker/LUKS) or how factors are held outside the cloud.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "8.5", "8.2" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "3.11", "6.8" ] } }, { "id": 43, "numero_regla": "3.6.1", "requisito": "3", "seccion": "3.6", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Claves criptográficas que protegen datos de cuenta almacenados aseguradas", "seccion_titulo_en": "Cryptographic keys used to protect stored account data are secured", "descripcion_corta": "Procedimientos para proteger llaves criptográficas contra divulgación y uso indebido", "descripcion_larga": "Deben definirse e implementarse procedimientos para proteger contra divulgación y uso indebido las llaves que protegen datos de cuenta almacenados, incluyendo: acceso restringido al menor número de custodios necesario; llaves de cifrado de llaves (KEK) al menos tan robustas como las llaves de cifrado de datos (DEK) que protegen; KEK almacenadas por separado de las DEK; y llaves guardadas de forma segura en el menor número posible de ubicaciones y formas. Aplica tanto a DEK como a KEK, y estas últimas requieren protección reforzada porque una sola puede dar acceso a muchas DEK.", "remediacion": "1) Documente procedimientos de gestión de llaves para KMS, Key Vault y Cloud KMS. 2) Use cifrado de sobre (envelope encryption): las DEK se cifran con CMK que nunca salen del HSM del servicio, y las CMK son AES-256 o equivalentes de igual o mayor fuerza que las DEK. 3) Restrinja la administración y el uso de llaves: políticas de llave sin comodines, separación entre administradores de llave (Create/Put/Schedule) y usuarios (Encrypt/Decrypt), sin kms:Decrypt sobre '*' [KMS.1] [KMS.2], sin acceso público [KMS.5]; en Azure use RBAC de Key Vault y separe Key Vault Administrator de Crypto User; en GCP separe cloudkms.admin de cryptoKeyEncrypterDecrypter. 4) Monitoree uso de llaves con CloudTrail, diagnósticos de Key Vault y Cloud Audit Logs. 5) Evidencia: procedimientos, políticas de llave y lista de custodios.", "descripcion_corta_en": "Procedures to protect cryptographic keys against disclosure and misuse", "descripcion_larga_en": "Procedures must be defined and implemented to protect keys used to secure stored account data against disclosure and misuse, including: access limited to the fewest custodians necessary; key-encrypting keys (KEKs) at least as strong as the data-encrypting keys (DEKs) they protect; KEKs stored separately from DEKs; and keys stored securely in the fewest possible locations and forms. It covers both DEKs and KEKs, and KEKs need stronger protection because one may unlock many DEKs.", "remediacion_en": "1) Document key-management procedures for KMS, Key Vault and Cloud KMS. 2) Use envelope encryption: DEKs are encrypted with CMKs that never leave the service HSM, and CMKs are AES-256 or otherwise at least as strong as the DEKs. 3) Restrict key administration and use: key policies without wildcards, separation between key administrators (Create/Put/Schedule) and key users (Encrypt/Decrypt), no kms:Decrypt on '*' [KMS.1] [KMS.2], no public access [KMS.5]; in Azure use Key Vault RBAC and separate Key Vault Administrator from Crypto User; in GCP separate cloudkms.admin from cryptoKeyEncrypterDecrypter. 4) Monitor key use with CloudTrail, Key Vault diagnostics and Cloud Audit Logs. 5) Evidence: procedures, key policies and custodian list.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 100, "pagina_pdf_es": 109 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [ "Políticas IAM administradas o inline que permiten kms:Decrypt/kms:ReEncryptFrom sobre todas las llaves [KMS.1] [KMS.2]", "Políticas de llave KMS con Principal \"*\" sin condiciones (falla si existe) [KMS.5]", "Principales con kms:* y a la vez administración y uso (Create/PutKeyPolicy y Decrypt) sobre CMK del CDE (falla: sin separación de funciones)", "CloudTrail registrando eventos de KMS en todas las regiones [CloudTrail.1]" ], "checks_azure": [ "Key Vaults del CDE con enableRbacAuthorization = true (o access policies sin permisos 'all')", "Asignaciones de Key Vault Administrator y Key Vault Crypto User/Officer al mismo principal (falla: sin separación)", "Key Vaults con diagnostic settings AuditEvent hacia Log Analytics" ], "checks_gcp": [ "Separación de funciones: miembros con roles/cloudkms.admin y roles/cloudkms.cryptoKeyEncrypterDecrypter a la vez (falla si existe; CIS GCP 1.11)", "CryptoKeys sin allUsers/allAuthenticatedUsers (CIS GCP 1.9)", "Data Access audit logs habilitados para cloudkms.googleapis.com" ], "evidencia": "Procedimientos de gestión de llaves, políticas de llave y asignaciones IAM/RBAC, lista de custodios y diseño de cifrado de sobre.", "evidencia_en": "Key-management procedures, key policies and IAM/RBAC assignments, custodian list and envelope encryption design.", "limitaciones": "Kyber no valida DEK gestionadas por la aplicación ni el número mínimo de custodios necesario, que es un juicio del negocio.", "limitaciones_en": "Kyber does not validate application-managed DEKs or the minimum custodian count, which is a business judgment.", "responsabilidad_compartida": "compartida", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "5.15", "8.2" ], "soc2_tsc": [ "CC6.1", "CC6.3" ], "cis_controls_v8": [ "3.11", "6.8" ], "banxico_spei": [ "58a. I.A.d).5" ] } }, { "id": 44, "numero_regla": "3.6.1.1", "requisito": "3", "seccion": "3.6", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Claves criptográficas que protegen datos de cuenta almacenados aseguradas", "seccion_titulo_en": "Cryptographic keys used to protect stored account data are secured", "descripcion_corta": "Proveedores de servicio: arquitectura criptográfica documentada", "descripcion_larga": "Requisito adicional solo para proveedores de servicio: debe mantenerse una descripción documentada de la arquitectura criptográfica que incluya los algoritmos, protocolos y llaves usados para proteger datos de cuenta almacenados (con fuerza de la llave y fecha de expiración), la prevención del uso de las mismas llaves en producción y pruebas, la descripción del uso de cada llave y un inventario de HSM, sistemas de gestión de llaves (KMS) y otros dispositivos criptográficos seguros (SCD) con tipo y ubicación, para apoyar el Requisito 12.3.4. En HSM en la nube la responsabilidad se comparte entre proveedor y cliente. El punto sobre producción y pruebas fue mejor práctica hasta el 31 de marzo de 2025.", "remediacion": "1) Genere un inventario de llaves: AWS KMS (KeySpec, KeyUsage, Origin, CustomKeyStore, MultiRegion, rotación), CloudHSM clusters, Azure Key Vault/Managed HSM (kty, key_size, exp) y Cloud KMS (algorithm, protectionLevel, rotationPeriod, ubicación). 2) Documente para cada llave su uso (qué recurso o dato protege), fuerza y fecha de expiración o rotación. 3) Separe llaves de producción y pruebas por cuenta/suscripción/proyecto y etiquete el entorno; impida con SCP/Azure Policy/Organization Policy que cuentas de pruebas usen llaves de producción. 4) Liste HSM/KMS con tipo, región y referencia a la certificación FIPS 140 del proveedor. 5) Revise el documento al menos anualmente. 6) Evidencia: documento de arquitectura criptográfica e inventario actualizado.", "descripcion_corta_en": "Service providers: documented cryptographic architecture", "descripcion_larga_en": "Additional requirement for service providers only: a documented description of the cryptographic architecture must be maintained, including algorithms, protocols and keys used to protect stored account data (with key strength and expiry date), prevention of using the same keys in production and test, a description of each key's usage, and an inventory of HSMs, key management systems (KMS) and other secure cryptographic devices (SCDs) with type and location, supporting Requirement 12.3.4. In cloud HSM implementations responsibility is shared between provider and customer. The production/test bullet was a best practice until 31 March 2025.", "remediacion_en": "1) Generate a key inventory: AWS KMS (KeySpec, KeyUsage, Origin, CustomKeyStore, MultiRegion, rotation), CloudHSM clusters, Azure Key Vault/Managed HSM (kty, key_size, exp) and Cloud KMS (algorithm, protectionLevel, rotationPeriod, location). 2) Document each key's usage (which resource or data it protects), strength and expiry or rotation date. 3) Separate production and test keys by account/subscription/project and tag the environment; use SCPs/Azure Policy/Organization Policy to prevent test accounts from using production keys. 4) List HSMs/KMS with type, region and reference to the provider's FIPS 140 certification. 5) Review the document at least annually. 6) Evidence: cryptographic architecture document and current inventory.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 101, "pagina_pdf_es": 111 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Inventario de CMK (DescribeKey: KeySpec, KeyUsage, Origin, MultiRegion, KeyState) y estado de rotación por región", "Inventario de clústeres CloudHSM y custom key stores con región y estado", "Llaves KMS usadas por recursos de cuentas de pruebas y producción a la vez (falla si existe)", "CMK sin etiqueta de entorno/uso (falla si existe)" ], "checks_azure": [ "Inventario de llaves de Key Vault/Managed HSM (kty, key_size, attributes.exp, ubicación)", "Llaves de Key Vault sin fecha de expiración (attributes.exp) definida (falla si existe)", "Vaults compartidos entre suscripciones de producción y pruebas (falla si existe)" ], "checks_gcp": [ "Inventario de KeyRings/CryptoKeys (algorithm, protectionLevel, rotationPeriod, ubicación)", "CryptoKeys de proyectos de producción con permisos IAM para cuentas de servicio de proyectos de pruebas (falla si existe)" ], "evidencia": "Documento de arquitectura criptográfica con inventario de llaves, algoritmos, protocolos, usos y dispositivos generado por Kyber y validado por el cliente.", "evidencia_en": "Cryptographic architecture document with key, algorithm, protocol, usage and device inventory generated by Kyber and validated by the customer.", "limitaciones": "Kyber no ve llaves gestionadas fuera de los servicios de nube (en aplicación u on-prem) ni puede determinar por sí solo el propósito de negocio de cada llave.", "limitaciones_en": "Kyber cannot see keys managed outside cloud services (in-app or on-prem) nor determine each key's business purpose on its own.", "responsabilidad_compartida": "compartida", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "5.9" ], "soc2_tsc": [ "CC6.1", "CC3.4" ], "cis_controls_v8": [ "3.11", "1.1" ] } }, { "id": 45, "numero_regla": "3.6.1.2", "requisito": "3", "seccion": "3.6", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Claves criptográficas que protegen datos de cuenta almacenados aseguradas", "seccion_titulo_en": "Cryptographic keys used to protect stored account data are secured", "descripcion_corta": "Llaves secretas y privadas almacenadas cifradas con KEK, en SCD/HSM o como componentes", "descripcion_larga": "Las llaves secretas y privadas que protegen datos de cuenta almacenados deben existir en todo momento en al menos una de estas formas: cifradas con una KEK al menos tan robusta como la DEK y guardada por separado; dentro de un dispositivo criptográfico seguro (SCD), como un HSM o un dispositivo de punto de interacción aprobado por PTS; o como al menos dos componentes de llave o partes compartidas de longitud completa según un método aceptado por la industria. Las llaves públicas no requieren estas formas y se aceptan llaves en un KMS que use SCD. Dividir una llave en dos mitades no cumple; los componentes deben generarse con un generador aleatorio aprobado dentro de un SCD o conforme a ISO 19592 o equivalente.", "remediacion": "1) Mantenga las CMK en servicios respaldados por HSM validados FIPS 140 (AWS KMS, CloudHSM, Azure Key Vault Premium/Managed HSM, Cloud KMS/Cloud HSM) y use cifrado de sobre para que las DEK solo se almacenen cifradas. 2) Prohíba llaves en texto claro en código, variables de entorno, user-data, parámetros o archivos de configuración; use Secrets Manager/SSM SecureString, Key Vault secrets o Secret Manager cifrados con CMK. 3) Para llaves importadas (BYOK) documente el método de generación y transporte. 4) Para cargas de mayor sensibilidad use claves HSM (Key Vault kty RSA-HSM/EC-HSM/oct-HSM, Cloud KMS protectionLevel HSM, KMS con custom key store CloudHSM). 5) Evidencia: configuración de servicios de llaves, hallazgos de búsqueda de secretos y procedimiento documentado.", "descripcion_corta_en": "Secret and private keys stored encrypted with a KEK, in an SCD/HSM or as components", "descripcion_larga_en": "Secret and private keys protecting stored account data must at all times exist in at least one of these forms: encrypted with a KEK at least as strong as the DEK and stored separately; inside a secure cryptographic device (SCD) such as an HSM or PTS-approved point-of-interaction device; or as at least two full-length key components or key shares per an industry-accepted method. Public keys are exempt and keys held in a KMS using SCDs are acceptable. Splitting a key into two halves does not comply; components must be generated with an approved random number generator inside an SCD or per ISO 19592 or equivalent.", "remediacion_en": "1) Keep CMKs in FIPS 140-validated HSM-backed services (AWS KMS, CloudHSM, Azure Key Vault Premium/Managed HSM, Cloud KMS/Cloud HSM) and use envelope encryption so DEKs are only stored encrypted. 2) Prohibit cleartext keys in code, environment variables, user-data, parameters or config files; use Secrets Manager/SSM SecureString, Key Vault secrets or Secret Manager encrypted with CMKs. 3) For imported keys (BYOK) document the generation and transport method. 4) For higher-sensitivity workloads use HSM keys (Key Vault kty RSA-HSM/EC-HSM/oct-HSM, Cloud KMS protectionLevel HSM, KMS with a CloudHSM custom key store). 5) Evidence: key service configuration, secret-scanning findings and documented procedure.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 103, "pagina_pdf_es": 113 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Variables de entorno de Lambda, user-data de EC2 y task definitions de ECS con material de llave o secretos en texto claro (falla si existe)", "Parámetros SSM con nombres de llave/secreto de tipo String en lugar de SecureString (falla si existe)", "CMK con Origin EXTERNAL (material importado) sin documentación de generación (revisión)", "Escaneo de snapshots EBS en busca de archivos de llave privada o llaves simétricas en claro (falla si existe)" ], "checks_azure": [ "App Service/Functions: app settings con llaves o secretos en claro en lugar de referencias a Key Vault (falla si existe)", "Key Vault SKU y tipo de llave (kty RSA-HSM/EC-HSM) para llaves del CDE (informativo)", "Escaneo de snapshots de Managed Disks en busca de llaves privadas en claro (falla si existe)" ], "checks_gcp": [ "Cloud Run/Cloud Functions: variables de entorno con llaves o secretos en claro en lugar de Secret Manager (falla si existe)", "CryptoKeys del CDE con protectionLevel SOFTWARE donde la política exige HSM (revisión)", "Escaneo de snapshots de Persistent Disk en busca de llaves privadas en claro (falla si existe)" ], "evidencia": "Configuración de servicios de llaves (protección HSM), resultados de búsqueda de secretos en configuraciones y snapshots, procedimiento de almacenamiento de llaves.", "evidencia_en": "Key service configuration (HSM protection), secret-scanning results across configurations and snapshots, key storage procedure.", "limitaciones": "La protección HSM del servicio es heredada del proveedor (ver AWS Artifact/Service Trust Portal/Compliance Reports Manager); Kyber no inspecciona repositorios de código ni la generación de componentes manuales.", "limitaciones_en": "Service HSM protection is inherited from the provider (see AWS Artifact/Service Trust Portal/Compliance Reports Manager); Kyber does not inspect code repositories or manual component generation.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.24" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "3.11" ] } }, { "id": 46, "numero_regla": "3.6.1.3", "requisito": "3", "seccion": "3.6", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Claves criptográficas que protegen datos de cuenta almacenados aseguradas", "seccion_titulo_en": "Cryptographic keys used to protect stored account data are secured", "descripcion_corta": "Acceso a componentes de llave en texto claro restringido al mínimo de custodios", "descripcion_larga": "El acceso a los componentes de llaves criptográficas en texto claro debe limitarse al menor número de custodios necesario. Solo el personal con responsabilidades de custodio definidas (crear, modificar, rotar, distribuir o mantener llaves) debería tener acceso a los componentes, idealmente un grupo muy reducido.", "remediacion": "1) Identifique dónde existen componentes de llave en claro: importación de material a KMS (BYOK), usuarios crypto officer de CloudHSM, security domain de Azure Managed HSM, import jobs de Cloud KMS o HSM de pago. 2) Limite los permisos kms:ImportKeyMaterial/GetParametersForImport, Managed HSM Crypto Officer y cloudkms.importer a un grupo nominal de custodios. 3) Evite llaves exportables; prefiera material generado dentro del HSM. 4) Revise la lista de custodios al menos semestralmente y tras bajas de personal. 5) Evidencia: lista de usuarios con acceso, asignaciones IAM/RBAC y registros de revisión.", "descripcion_corta_en": "Access to cleartext key components restricted to fewest custodians", "descripcion_larga_en": "Access to cleartext cryptographic key components must be restricted to the fewest custodians necessary. Only personnel with defined custodian duties (creating, changing, rotating, distributing or maintaining keys) should have access to key components, ideally a very small group.", "remediacion_en": "1) Identify where cleartext key components exist: key material import into KMS (BYOK), CloudHSM crypto officer users, Azure Managed HSM security domain, Cloud KMS import jobs or payment HSMs. 2) Limit kms:ImportKeyMaterial/GetParametersForImport, Managed HSM Crypto Officer and cloudkms.importer permissions to a named custodian group. 3) Avoid exportable keys; prefer material generated inside the HSM. 4) Review the custodian list at least semi-annually and after staff departures. 5) Evidence: access user list, IAM/RBAC assignments and review records.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 104, "pagina_pdf_es": 115 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Principales IAM con kms:ImportKeyMaterial o kms:GetParametersForImport (listado; falla si exceden la lista de custodios)", "CMK con Origin EXTERNAL y sus políticas de llave (listado de quién puede importar material)", "Usuarios CloudHSM y roles con cloudhsm:* (listado para conciliación con custodios)" ], "checks_azure": [ "Azure Managed HSM: asignaciones locales de Managed HSM Crypto Officer/Administrator (listado; falla si exceden custodios)", "Key Vault: principales con permisos import/backup/restore sobre llaves del CDE (listado)" ], "checks_gcp": [ "Principales con roles/cloudkms.importer o permisos cloudkms.importJobs.* (listado; falla si exceden custodios)", "CryptoKeys con versiones importadas (importJob presente) y su IAM (revisión)" ], "evidencia": "Lista de custodios autorizados conciliada contra asignaciones IAM/RBAC generadas por Kyber.", "evidencia_en": "Authorized custodian list reconciled against IAM/RBAC assignments generated by Kyber.", "limitaciones": "Con llaves generadas y no exportables en KMS no existen componentes en claro; Kyber no ve componentes en papel, tarjetas inteligentes ni HSM fuera de la nube.", "limitaciones_en": "With non-exportable KMS-generated keys no cleartext components exist; Kyber cannot see components on paper, smart cards or off-cloud HSMs.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.2", "8.24", "5.15" ], "soc2_tsc": [ "CC6.1", "CC6.3" ], "cis_controls_v8": [ "6.8", "5.4" ] } }, { "id": 47, "numero_regla": "3.6.1.4", "requisito": "3", "seccion": "3.6", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Claves criptográficas que protegen datos de cuenta almacenados aseguradas", "seccion_titulo_en": "Cryptographic keys used to protect stored account data are secured", "descripcion_corta": "Llaves criptográficas almacenadas en el menor número posible de ubicaciones", "descripcion_larga": "Las llaves criptográficas deben guardarse en el menor número posible de ubicaciones, lo que facilita rastrearlas, monitorearlas y reduce el riesgo de exposición a terceros no autorizados. Las llaves solo deben conservarse donde sea necesario.", "remediacion": "1) Centralice las llaves en un número reducido de servicios gestionados (KMS por cuenta designada, Key Vaults dedicados, proyecto de Cloud KMS central). 2) Evite llaves multi-región o réplicas innecesarias (KMS MultiRegion, respaldos de Key Vault, copias en múltiples regiones). 3) Elimine copias de llaves en código, servidores, buckets o equipos personales. 4) Mantenga un inventario de ubicaciones de llaves y revíselo periódicamente. 5) Evidencia: inventario de ubicaciones, configuración de servicios y resultados de búsqueda de llaves fuera de los almacenes aprobados.", "descripcion_corta_en": "Cryptographic keys stored in the fewest possible locations", "descripcion_larga_en": "Cryptographic keys must be stored in the fewest possible locations, which makes them easier to track and monitor and lowers the risk of exposure to unauthorized parties. Keys should be kept only where necessary.", "remediacion_en": "1) Centralize keys in a small number of managed services (KMS in a designated account, dedicated Key Vaults, a central Cloud KMS project). 2) Avoid unnecessary multi-region keys or replicas (KMS MultiRegion, Key Vault backups, copies across regions). 3) Remove key copies from code, servers, buckets or personal devices. 4) Maintain and periodically review an inventory of key locations. 5) Evidence: location inventory, service configuration and results of searches for keys outside approved stores.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 105, "pagina_pdf_es": 115 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Inventario de CMK por cuenta y región, incluyendo llaves MultiRegion y réplicas (revisión de necesidad)", "Objetos S3 y snapshots EBS con archivos de llave (.pem, .key, .p12, .jks) fuera de los almacenes aprobados (falla si existe)", "Secretos duplicados en Secrets Manager entre regiones/cuentas sin justificación (revisión)" ], "checks_azure": [ "Inventario de Key Vaults/Managed HSM por suscripción y región y número de llaves por vault", "Blobs y snapshots con archivos de llave fuera de Key Vault (falla si existe)" ], "checks_gcp": [ "Inventario de KeyRings por proyecto y ubicación (incluidas ubicaciones multirregionales/global)", "Objetos de Cloud Storage y snapshots con archivos de llave fuera de Cloud KMS/Secret Manager (falla si existe)" ], "evidencia": "Inventario de ubicaciones de llaves generado por Kyber y hallazgos de llaves fuera de almacenes aprobados.", "evidencia_en": "Kyber-generated key location inventory and findings of keys outside approved stores.", "limitaciones": "No cubre ubicaciones fuera de la nube (equipos, papel, repositorios de código) ni determina cuántas ubicaciones son estrictamente necesarias.", "limitaciones_en": "Does not cover off-cloud locations (devices, paper, code repositories) nor determine how many locations are strictly necessary.", "responsabilidad_compartida": "cliente", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "5.9" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "3.11", "1.1" ] } }, { "id": 48, "numero_regla": "3.7.1", "requisito": "3", "seccion": "3.7", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Procesos de gestión del ciclo de vida de claves criptográficas", "seccion_titulo_en": "Key-management processes covering all aspects of the key lifecycle", "descripcion_corta": "Gestión de llaves incluye la generación de llaves criptográficas robustas", "descripcion_larga": "Las políticas y procedimientos de gestión de llaves deben implementarse para que las llaves que protegen datos de cuenta almacenados se generen de forma robusta. El evaluador revisa que la documentación defina cómo se generan y observa el método para confirmar que produce llaves fuertes.", "remediacion": "1) Genere llaves dentro de los HSM del servicio (KMS Origin AWS_KMS o AWS_CLOUDHSM, Key Vault/Managed HSM, Cloud KMS) en lugar de importarlas. 2) Defina tamaños y algoritmos mínimos: AES-256 (SYMMETRIC_DEFAULT, GOOGLE_SYMMETRIC_ENCRYPTION), RSA ≥ 2048 (preferible 3072) y ECC P-256 o superior. 3) Aplique Azure Policy para tamaño mínimo de llave RSA y curvas permitidas en Key Vault, y restricciones equivalentes en IaC. 4) Si se importa material (BYOK), documente que se generó en un SCD con un generador aleatorio aprobado. 5) Evidencia: procedimiento de generación, inventario de llaves con algoritmo/tamaño y configuraciones de política.", "descripcion_corta_en": "Key management includes generation of strong cryptographic keys", "descripcion_larga_en": "Key-management policies and procedures must be implemented so that keys protecting stored account data are generated strongly. The assessor checks that documentation defines how keys are generated and observes the method to confirm it yields strong keys.", "remediacion_en": "1) Generate keys inside the service HSMs (KMS Origin AWS_KMS or AWS_CLOUDHSM, Key Vault/Managed HSM, Cloud KMS) rather than importing them. 2) Define minimum sizes and algorithms: AES-256 (SYMMETRIC_DEFAULT, GOOGLE_SYMMETRIC_ENCRYPTION), RSA ≥ 2048 (3072 preferred) and ECC P-256 or higher. 3) Apply Azure Policy for minimum RSA key size and allowed curves in Key Vault, and equivalent IaC guardrails. 4) If material is imported (BYOK), document it was generated in an SCD with an approved random number generator. 5) Evidence: generation procedure, key inventory with algorithm/size and policy configurations.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 106, "pagina_pdf_es": 116 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [ "CMK con KeySpec RSA_1024 o inferior a la política, o asimétricas de tamaño insuficiente (falla si existe)", "CMK con Origin EXTERNAL (material importado) para datos de cuenta (revisión de procedimiento de generación)" ], "checks_azure": [ "Llaves de Key Vault RSA con key_size < 2048 (falla si existe)", "Azure Policy de tamaño mínimo de llave RSA y curvas elípticas permitidas asignada a los Key Vaults del CDE" ], "checks_gcp": [ "CryptoKeys con algoritmos RSA de 2048 bits o menos donde la política exige más, o algoritmos no aprobados (revisión)", "CryptoKeyVersions importadas (importJob) para datos de cuenta (revisión de procedimiento de generación)" ], "evidencia": "Procedimiento de generación de llaves, inventario con algoritmo y tamaño, y evidencia de origen del material.", "evidencia_en": "Key generation procedure, inventory with algorithm and size, and evidence of key material origin.", "limitaciones": "La calidad de la generación dentro del HSM es heredada del proveedor; Kyber no observa llaves generadas por aplicaciones.", "limitaciones_en": "Generation quality inside the HSM is inherited from the provider; Kyber does not observe application-generated keys.", "responsabilidad_compartida": "compartida", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.24" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "3.11" ] }, "mapeo_ucf": [ { "clave": "UCF-CRY-003", "relacion": "partial", "cobertura_pct": 40 } ] }, { "id": 49, "numero_regla": "3.7.2", "requisito": "3", "seccion": "3.7", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Procesos de gestión del ciclo de vida de claves criptográficas", "seccion_titulo_en": "Key-management processes covering all aspects of the key lifecycle", "descripcion_corta": "Gestión de llaves incluye la distribución segura de llaves criptográficas", "descripcion_larga": "Las políticas y procedimientos de gestión de llaves deben cubrir la distribución segura de las llaves que protegen datos de cuenta almacenados. Las llaves secretas o privadas solo deben entregarse a custodios autorizados y nunca transmitirse de forma insegura.", "remediacion": "1) Evite distribuir material de llave: otorgue uso de la CMK por permisos (políticas de llave, grants, RBAC, IAM) en lugar de copiarla. 2) Cuando deba transportarse material (BYOK, intercambio con terceros), use los mecanismos de envoltura del servicio (GetParametersForImport con RSA-OAEP, Key Vault BYOK con KEK HSM, Cloud KMS import jobs) o componentes con control dual. 3) Restrinja el acceso compartido entre cuentas a principales específicos y revise grants periódicamente. 4) Acceda a los servicios de llaves por redes privadas (VPC endpoints, Private Endpoints, Private Service Connect) y TLS 1.2+. 5) Evidencia: procedimiento de distribución, registros de importación y revisión de grants y accesos entre cuentas.", "descripcion_corta_en": "Key management includes secure distribution of cryptographic keys", "descripcion_larga_en": "Key-management policies and procedures must cover secure distribution of keys protecting stored account data. Secret or private keys must only be delivered to authorized custodians and never transmitted insecurely.", "remediacion_en": "1) Avoid distributing key material: grant CMK usage through permissions (key policies, grants, RBAC, IAM) instead of copying it. 2) When material must be transported (BYOK, third-party exchange), use the service's wrapping mechanisms (GetParametersForImport with RSA-OAEP, Key Vault BYOK with an HSM KEK, Cloud KMS import jobs) or components under dual control. 3) Limit cross-account sharing to specific principals and review grants periodically. 4) Reach key services over private networks (VPC endpoints, Private Endpoints, Private Service Connect) and TLS 1.2+. 5) Evidence: distribution procedure, import records and review of grants and cross-account access.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 106, "pagina_pdf_es": 116 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [ "Políticas de llave KMS que conceden acceso a cuentas externas (Principal de otra cuenta o \"*\") no aprobadas (falla si existe) [KMS.5]", "Grants de KMS activos sobre CMK del CDE (ListGrants) para revisión periódica", "VPC endpoint de KMS (com.amazonaws..kms) en VPC del CDE" ], "checks_azure": [ "Key Vaults del CDE con publicNetworkAccess = Disabled o networkAcls.defaultAction = Deny y Private Endpoint", "Asignaciones RBAC sobre llaves del CDE a principales de otros tenants (falla si no aprobado)" ], "checks_gcp": [ "IAM de CryptoKeys con miembros de otros dominios/organizaciones no aprobados (falla si existe)", "Import jobs de Cloud KMS registrados en Cloud Audit Logs (evidencia de transporte de material)" ], "evidencia": "Procedimiento de distribución, registros de importación de material y revisión de accesos/grants entre cuentas.", "evidencia_en": "Distribution procedure, key material import records and review of cross-account access/grants.", "limitaciones": "Kyber no observa la distribución fuera de los servicios de nube (papel, dispositivos, correo) ni la identidad real de quien recibe componentes.", "limitaciones_en": "Kyber does not observe distribution outside cloud services (paper, devices, email) or the actual identity of component recipients.", "responsabilidad_compartida": "compartida", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "5.14" ], "soc2_tsc": [ "CC6.1", "CC6.7" ], "cis_controls_v8": [ "3.11" ] } }, { "id": 50, "numero_regla": "3.7.3", "requisito": "3", "seccion": "3.7", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Procesos de gestión del ciclo de vida de claves criptográficas", "seccion_titulo_en": "Key-management processes covering all aspects of the key lifecycle", "descripcion_corta": "Gestión de llaves incluye el almacenamiento seguro de llaves criptográficas", "descripcion_larga": "Las políticas y procedimientos de gestión de llaves deben cubrir el almacenamiento seguro de las llaves que protegen datos de cuenta almacenados. Como buenas prácticas, las DEK pueden protegerse cifrándolas con una KEK o guardarse en un HSM, y las llaves secretas o privadas capaces de descifrar datos nunca deben estar en el código fuente.", "remediacion": "1) Almacene llaves solo en KMS/CloudHSM, Key Vault/Managed HSM o Cloud KMS, y secretos derivados en Secrets Manager, Key Vault secrets o Secret Manager cifrados con CMK. 2) Habilite protección contra borrado: Key Vault soft delete y purge protection, periodo de espera de borrado de KMS (7-30 días), destroyScheduledDuration de Cloud KMS. 3) Restrinja el acceso de red a los almacenes de llaves. 4) Ejecute escaneo de secretos en repositorios de código y pipelines. 5) Evidencia: configuraciones de almacenes, resultados de escaneo de secretos y procedimiento.", "descripcion_corta_en": "Key management includes secure storage of cryptographic keys", "descripcion_larga_en": "Key-management policies and procedures must cover secure storage of keys protecting stored account data. As good practice, DEKs may be protected by encrypting them with a KEK or stored in an HSM, and secret or private keys able to decrypt data must never be present in source code.", "remediacion_en": "1) Store keys only in KMS/CloudHSM, Key Vault/Managed HSM or Cloud KMS, and derived secrets in Secrets Manager, Key Vault secrets or Secret Manager encrypted with CMKs. 2) Enable deletion protection: Key Vault soft delete and purge protection, KMS deletion waiting period (7-30 days), Cloud KMS destroyScheduledDuration. 3) Restrict network access to key stores. 4) Run secret scanning on code repositories and pipelines. 5) Evidence: key store configurations, secret-scanning results and procedure.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 107, "pagina_pdf_es": 117 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Variables de entorno de Lambda/ECS y user-data de EC2 con llaves o secretos en texto claro (falla si existe)", "Secretos de Secrets Manager cifrados con aws/secretsmanager en lugar de CMK para datos del CDE (revisión)", "CMK en estado PendingDeletion usadas por recursos del CDE (falla si existe) [KMS.3]" ], "checks_azure": [ "Key Vaults con enablePurgeProtection = false o softDelete deshabilitado (falla si existe)", "Key Vaults del CDE sin Private Endpoint o con networkAcls.defaultAction = Allow (falla si existe)", "App settings con secretos en claro en lugar de referencias @Microsoft.KeyVault (falla si existe)" ], "checks_gcp": [ "Llaves de Cloud KMS sin allUsers/allAuthenticatedUsers (CIS GCP 1.9)", "Cloud Run/Functions con secretos en variables de entorno en claro en lugar de Secret Manager (falla si existe)", "CryptoKeys con destroyScheduledDuration menor al mínimo de la política (revisión)" ], "evidencia": "Configuraciones de almacenes de llaves y protección contra borrado, resultados de escaneo de secretos en configuraciones y procedimiento de almacenamiento.", "evidencia_en": "Key store and deletion-protection configurations, secret-scanning results in configurations and storage procedure.", "limitaciones": "Kyber no escanea repositorios de código fuente salvo integración específica; no cubre almacenamiento fuera de la nube.", "limitaciones_en": "Kyber does not scan source code repositories unless specifically integrated; off-cloud storage is not covered.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "8.4" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "3.11", "16.1" ] } }, { "id": 51, "numero_regla": "3.7.4", "requisito": "3", "seccion": "3.7", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Procesos de gestión del ciclo de vida de claves criptográficas", "seccion_titulo_en": "Key-management processes covering all aspects of the key lifecycle", "descripcion_corta": "Cambio de llaves al final de su criptoperiodo definido", "descripcion_larga": "Deben implementarse políticas y procedimientos para cambiar las llaves que llegan al final de su criptoperiodo, definido por el proveedor de la aplicación o el dueño de la llave con base en mejores prácticas de la industria. Deben incluir un criptoperiodo definido para cada tipo de llave en uso y un proceso de cambio de llaves al concluir dicho periodo. El criptoperiodo es el lapso en que una llave puede usarse para su propósito y suele definirse por tiempo y/o volumen de texto cifrado, considerando algoritmo, longitud, riesgo de compromiso y sensibilidad de los datos (ver NIST SP 800-57).", "remediacion": "1) Defina el criptoperiodo por tipo de llave (p. ej. CMK de datos 1 año, DEK por objeto, llaves TLS según vigencia del certificado) con base en NIST SP 800-57. 2) Habilite rotación automática: AWS KMS EnableKeyRotation con RotationPeriodInDays acorde a la política [KMS.4]; Azure Key Vault rotation policy con lifetimeActions Rotate y expiryTime; Cloud KMS rotationPeriod (≤ 90 días según CIS GCP 1.10, o el valor de la política) y nextRotationTime. 3) Para llaves importadas o asimétricas que no rotan automáticamente, documente y ejecute rotación manual (nueva llave + cambio de alias). 4) Vuelva a cifrar datos cuando la política lo exija. 5) Evidencia: política de criptoperiodos, configuración de rotación y fechas de última rotación.", "descripcion_corta_en": "Key changes at the end of the defined cryptoperiod", "descripcion_larga_en": "Policies and procedures must be implemented to change keys that reach the end of their cryptoperiod, as defined by the application vendor or key owner based on industry best practices. They must include a defined cryptoperiod for each key type in use and a process to change keys when it ends. A cryptoperiod is the time span a key may be used for its purpose, often defined by time and/or amount of ciphertext produced, considering algorithm, key length, compromise risk and data sensitivity (see NIST SP 800-57).", "remediacion_en": "1) Define the cryptoperiod per key type (e.g., data CMK 1 year, per-object DEKs, TLS keys per certificate validity) based on NIST SP 800-57. 2) Enable automatic rotation: AWS KMS EnableKeyRotation with RotationPeriodInDays per policy [KMS.4]; Azure Key Vault rotation policy with lifetimeActions Rotate and expiryTime; Cloud KMS rotationPeriod (≤ 90 days per CIS GCP 1.10, or the policy value) and nextRotationTime. 3) For imported or asymmetric keys that do not rotate automatically, document and perform manual rotation (new key + alias switch). 4) Re-encrypt data when the policy requires it. 5) Evidence: cryptoperiod policy, rotation configuration and last-rotation dates.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 108, "pagina_pdf_es": 118 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "CMK simétricas de cliente con KeyRotationEnabled = false (falla si existe) [KMS.4]", "CMK con RotationPeriodInDays mayor al criptoperiodo definido en la política (falla si existe)", "CMK asimétricas o con Origin EXTERNAL cuya fecha de creación supera el criptoperiodo sin llave sucesora (falla si existe)" ], "checks_azure": [ "Llaves de Key Vault sin rotation policy con acción Rotate (falla si existe)", "Llaves de Key Vault sin fecha de expiración (attributes.exp) o con expiración superior al criptoperiodo (falla si existe)", "Llaves con versión activa más antigua que el criptoperiodo (falla si existe)" ], "checks_gcp": [ "CryptoKeys ENCRYPT_DECRYPT sin rotationPeriod o con rotationPeriod > política (falla si existe; CIS GCP 1.10 recomienda ≤ 90 días)", "CryptoKeys asimétricas con versión primaria más antigua que el criptoperiodo (falla si existe)" ], "evidencia": "Política de criptoperiodos por tipo de llave y reporte de Kyber de estado de rotación y antigüedad de cada llave.", "evidencia_en": "Cryptoperiod policy per key type and Kyber report on rotation status and age of each key.", "limitaciones": "Kyber no evalúa llaves gestionadas por la aplicación (DEK propias) ni si el criptoperiodo definido es adecuado al riesgo.", "limitaciones_en": "Kyber does not evaluate application-managed keys (own DEKs) or whether the defined cryptoperiod suits the risk.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.24" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "3.11" ] } }, { "id": 52, "numero_regla": "3.7.5", "requisito": "3", "seccion": "3.7", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Procesos de gestión del ciclo de vida de claves criptográficas", "seccion_titulo_en": "Key-management processes covering all aspects of the key lifecycle", "descripcion_corta": "Retiro, reemplazo o destrucción de llaves al vencer, debilitarse o comprometerse", "descripcion_larga": "Las políticas y procedimientos deben incluir el retiro, reemplazo o destrucción de las llaves que protegen datos de cuenta almacenados cuando: la llave llegó al final de su criptoperiodo; su integridad se debilitó (incluida la salida de la empresa o del rol de una persona que conocía un componente en claro); o se sospecha o sabe que fue comprometida. Las llaves retiradas o reemplazadas no deben usarse para operaciones de cifrado y, si deben conservarse (p. ej. para descifrar datos archivados), deben archivarse de forma segura, por ejemplo con una KEK. Las llaves comprometidas se gestionan conforme al plan de respuesta a incidentes (12.10.1).", "remediacion": "1) Documente disparadores y pasos de retiro/reemplazo: fin de criptoperiodo, salida de custodios, sospecha de compromiso. 2) Para reemplazar, cree una nueva CMK o versión, cambie alias/referencias y vuelva a cifrar los datos; para retirar, deshabilite la llave o versión (KMS DisableKey, Key Vault enabled = false, Cloud KMS version DISABLED). 3) Use las versiones antiguas solo para descifrar y bloquee kms:Encrypt sobre llaves retiradas en la política. 4) Programe destrucción con periodo de espera (ScheduleKeyDeletion 7-30 días, purge en Key Vault, destroy en Cloud KMS) tras confirmar que no hay datos dependientes. 5) Integre el compromiso de llaves al plan de respuesta a incidentes. 6) Evidencia: procedimiento, registros de cambios de estado de llaves y tickets.", "descripcion_corta_en": "Key retirement, replacement or destruction when expired, weakened or compromised", "descripcion_larga_en": "Policies and procedures must include retirement, replacement or destruction of keys protecting stored account data when: the key reached the end of its cryptoperiod; its integrity was weakened (including when someone who knew a cleartext component leaves the company or that role); or it is suspected or known to be compromised. Retired or replaced keys must not be used for encryption and, if they must be kept (e.g., to decrypt archived data), must be securely archived, for example with a KEK. Compromised keys are handled under the incident response plan (12.10.1).", "remediacion_en": "1) Document triggers and steps for retirement/replacement: end of cryptoperiod, custodian departure, suspected compromise. 2) To replace, create a new CMK or version, switch aliases/references and re-encrypt data; to retire, disable the key or version (KMS DisableKey, Key Vault enabled = false, Cloud KMS version DISABLED). 3) Use old versions only for decryption and block kms:Encrypt on retired keys in policy. 4) Schedule destruction with a waiting period (ScheduleKeyDeletion 7-30 days, Key Vault purge, Cloud KMS destroy) after confirming no dependent data. 5) Integrate key compromise into the incident response plan. 6) Evidence: procedure, key state-change records and tickets.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 109, "pagina_pdf_es": 119 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [ "CMK en PendingDeletion aún referenciadas por recursos activos (falla si existe) [KMS.3]", "CMK deshabilitadas (KeyState Disabled) aún configuradas como llave de cifrado de recursos S3/EBS/RDS (falla si existe)", "Alarma o regla de EventBridge sobre DisableKey/ScheduleKeyDeletion en CloudTrail" ], "checks_azure": [ "Llaves de Key Vault vencidas (exp pasada) que siguen habilitadas (falla si existe)", "Recursos (Storage/SQL/Disk Encryption Sets) que referencian versiones de llave deshabilitadas o vencidas (falla si existe)" ], "checks_gcp": [ "CryptoKeyVersions DISABLED o DESTROY_SCHEDULED aún usadas como primaria (falla si existe)", "Recursos con CMEK apuntando a CryptoKeys cuya versión primaria supera el criptoperiodo (falla si existe)" ], "evidencia": "Procedimiento de retiro y reemplazo, historial de estados de llaves (CloudTrail, Key Vault logs, Cloud Audit Logs) y vínculo con el plan de respuesta a incidentes.", "evidencia_en": "Retirement and replacement procedure, key state history (CloudTrail, Key Vault logs, Cloud Audit Logs) and link to the incident response plan.", "limitaciones": "Kyber no puede saber si una llave está comprometida ni si un custodio dejó la organización.", "limitaciones_en": "Kyber cannot know whether a key is compromised or whether a custodian left the organization.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "5.26" ], "soc2_tsc": [ "CC6.1", "CC7.4" ], "cis_controls_v8": [ "3.11" ] } }, { "id": 53, "numero_regla": "3.7.6", "requisito": "3", "seccion": "3.7", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Procesos de gestión del ciclo de vida de claves criptográficas", "seccion_titulo_en": "Key-management processes covering all aspects of the key lifecycle", "descripcion_corta": "Operaciones manuales con llaves en claro bajo conocimiento dividido y control dual", "descripcion_larga": "Cuando el personal realice operaciones manuales de gestión de llaves en texto claro, las políticas y procedimientos deben exigir conocimiento dividido y control dual. Con conocimiento dividido cada persona solo conoce su componente y ninguno revela información de los demás ni de la llave; con control dual se requieren dos o más personas para usar una llave o realizar una función de gestión. Dividir una llave en dos partes no basta: los componentes deben generarse con un generador aleatorio aprobado en un SCD o conforme a ISO 19592 o equivalente. Ejemplos de operaciones manuales: generación, transmisión, carga, almacenamiento y destrucción.", "remediacion": "1) Elimine en lo posible las operaciones manuales con llaves en claro usando llaves generadas y no exportables en KMS, Key Vault o Cloud KMS. 2) Cuando sean necesarias (importación BYOK, carga en HSM de pago, recuperación del security domain), aplique quórum: AWS CloudHSM quorum authentication (M de N), Azure Managed HSM security domain con quórum de llaves RSA, ceremonias documentadas con al menos dos custodios. 3) Asegure que ningún custodio tenga acceso a suficientes componentes para reconstruir la llave, incluso tras reasignaciones. 4) Requiera aprobación de dos personas (p. ej. flujo de aprobación de cambios) para ScheduleKeyDeletion, PutKeyPolicy e importación. 5) Evidencia: procedimiento de ceremonias, actas firmadas y configuración de quórum.", "descripcion_corta_en": "Manual cleartext key operations under split knowledge and dual control", "descripcion_larga_en": "Where personnel perform manual cleartext key-management operations, policies and procedures must require split knowledge and dual control. Under split knowledge each person knows only their own component and no component reveals anything about the others or the key; under dual control two or more people are needed to use a key or perform a management function. Simply splitting a key in two is not enough: components must be generated with an approved random number generator in an SCD or per ISO 19592 or equivalent. Examples of manual operations include generation, transmission, loading, storage and destruction.", "remediacion_en": "1) Eliminate manual cleartext key operations where possible by using non-exportable keys generated in KMS, Key Vault or Cloud KMS. 2) Where needed (BYOK import, payment HSM loading, security domain recovery), apply quorum: AWS CloudHSM quorum authentication (M of N), Azure Managed HSM security domain with an RSA key quorum, documented ceremonies with at least two custodians. 3) Ensure no custodian can access enough components to rebuild the key, even after reassignments. 4) Require two-person approval (e.g., change approval workflow) for ScheduleKeyDeletion, PutKeyPolicy and imports. 5) Evidence: ceremony procedure, signed minutes and quorum configuration.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 110, "pagina_pdf_es": 120 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [ "Inventario de CMK con Origin EXTERNAL (indica operaciones manuales de importación que requieren control dual)", "Clústeres CloudHSM en uso para datos de cuenta (requieren evidencia de quorum authentication)" ], "checks_azure": [ "Managed HSM: security domain activado (informativo) y número de llaves de quórum documentado", "Llaves BYOK importadas en Key Vault/Managed HSM (listado para revisión de ceremonias)" ], "checks_gcp": [ "CryptoKeyVersions importadas mediante import jobs (listado para revisión de ceremonias)" ], "evidencia": "Procedimientos y actas de ceremonias de llaves con firmas de al menos dos custodios, y configuración de quórum de HSM.", "evidencia_en": "Key ceremony procedures and minutes signed by at least two custodians, and HSM quorum configuration.", "limitaciones": "El conocimiento dividido y el control dual son controles procedimentales; Kyber solo identifica dónde existen operaciones manuales.", "limitaciones_en": "Split knowledge and dual control are procedural; Kyber only identifies where manual operations exist.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "5.3" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "3.11" ] } }, { "id": 54, "numero_regla": "3.7.7", "requisito": "3", "seccion": "3.7", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Procesos de gestión del ciclo de vida de claves criptográficas", "seccion_titulo_en": "Key-management processes covering all aspects of the key lifecycle", "descripcion_corta": "Prevención de la sustitución no autorizada de llaves criptográficas", "descripcion_larga": "Las políticas y procedimientos de gestión de llaves deben impedir la sustitución no autorizada de las llaves que protegen datos de cuenta almacenados. Si un atacante logra reemplazar una llave por otra que conoce, podrá descifrar todos los datos cifrados con ella; la solución no debe aceptar llaves de fuentes no autorizadas ni procesos inesperados.", "remediacion": "1) Restrinja quién puede cambiar referencias de llaves: kms:UpdateAlias, kms:PutKeyPolicy, kms:ImportKeyMaterial, cambios de llave en recursos (p. ej. s3:PutEncryptionConfiguration), Key Vault keys/import y rotate, cloudkms.cryptoKeyVersions.create/updatePrimaryVersion. 2) Use SCP, Azure Policy u Organization Policy (p. ej. restringir CMEK a proyectos de llaves aprobados con constraints/gcp.restrictCmekCryptoKeyProjects) para impedir llaves no aprobadas. 3) Alerte en tiempo real sobre cambios de alias, políticas, importaciones y versión primaria. 4) Exija aprobación de cambios para cualquier sustitución. 5) Evidencia: políticas de restricción, reglas de alerta y registros de cambios aprobados.", "descripcion_corta_en": "Prevention of unauthorized substitution of cryptographic keys", "descripcion_larga_en": "Key-management policies and procedures must prevent unauthorized substitution of keys protecting stored account data. If an attacker can replace a key with one they know, they can decrypt all data encrypted with it; the solution must not accept keys from unauthorized sources or unexpected processes.", "remediacion_en": "1) Restrict who can change key references: kms:UpdateAlias, kms:PutKeyPolicy, kms:ImportKeyMaterial, key changes on resources (e.g., s3:PutEncryptionConfiguration), Key Vault keys/import and rotate, cloudkms.cryptoKeyVersions.create/updatePrimaryVersion. 2) Use SCPs, Azure Policy or Organization Policy (e.g., restrict CMEK to approved key projects with constraints/gcp.restrictCmekCryptoKeyProjects) to block unapproved keys. 3) Alert in real time on alias, policy, import and primary version changes. 4) Require change approval for any substitution. 5) Evidence: restriction policies, alert rules and approved change records.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 111, "pagina_pdf_es": 122 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [ "Principales con kms:UpdateAlias, kms:PutKeyPolicy o kms:ImportKeyMaterial fuera del grupo de administradores de llaves (falla si existe)", "Regla de EventBridge/alarma de CloudWatch sobre UpdateAlias, PutKeyPolicy, ImportKeyMaterial y DisableKey", "SCP que restringe operaciones de administración de KMS a roles aprobados (revisión)" ], "checks_azure": [ "Alertas de Azure Monitor sobre operaciones de Key Vault (KeyImport, KeyUpdate, SetKeyRotationPolicy)", "Principales con permisos de import/update de llaves fuera de los custodios (falla si existe)" ], "checks_gcp": [ "Organization Policy constraints/gcp.restrictCmekCryptoKeyProjects aplicada a proyectos del CDE", "Alertas sobre UpdateCryptoKeyPrimaryVersion, ImportCryptoKeyVersion y SetIamPolicy en Cloud KMS" ], "evidencia": "Políticas de restricción de cambios de llave, reglas de alerta y registros de cambios aprobados.", "evidencia_en": "Key-change restriction policies, alert rules and approved change records.", "limitaciones": "No cubre llaves gestionadas por la aplicación ni valida que las alertas sean atendidas.", "limitaciones_en": "Does not cover application-managed keys nor validate that alerts are acted upon.", "responsabilidad_compartida": "compartida", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "8.32" ], "soc2_tsc": [ "CC6.1", "CC8.1" ], "cis_controls_v8": [ "3.11" ] } }, { "id": 55, "numero_regla": "3.7.8", "requisito": "3", "seccion": "3.7", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Procesos de gestión del ciclo de vida de claves criptográficas", "seccion_titulo_en": "Key-management processes covering all aspects of the key lifecycle", "descripcion_corta": "Custodios de llaves reconocen formalmente sus responsabilidades", "descripcion_larga": "Las políticas y procedimientos de gestión de llaves deben exigir que los custodios de llaves criptográficas reconozcan formalmente, por escrito o en forma electrónica, que entienden y aceptan sus responsabilidades como custodios. Una reafirmación anual ayuda a recordarles dichas responsabilidades.", "remediacion": "1) Defina las responsabilidades del custodio (generación, distribución, almacenamiento, rotación, retiro, ceremonias y reporte de incidentes). 2) Identifique a los custodios a partir de las asignaciones de administración de KMS, Key Vault/Managed HSM y Cloud KMS. 3) Recabe un acuse firmado o electrónico de cada custodio antes de otorgar acceso. 4) Repita la confirmación al menos anualmente y en cambios de rol. 5) Evidencia: formato de acuse, acuses firmados y conciliación con la lista de custodios.", "descripcion_corta_en": "Key custodians formally acknowledge their responsibilities", "descripcion_larga_en": "Key-management policies and procedures must require cryptographic key custodians to formally acknowledge, in writing or electronically, that they understand and accept their custodian responsibilities. An annual reaffirmation helps remind them of those responsibilities.", "remediacion_en": "1) Define custodian responsibilities (generation, distribution, storage, rotation, retirement, ceremonies and incident reporting). 2) Identify custodians from KMS, Key Vault/Managed HSM and Cloud KMS administrative assignments. 3) Collect a signed or electronic acknowledgment from each custodian before granting access. 4) Repeat at least annually and on role changes. 5) Evidence: acknowledgment form, signed acknowledgments and reconciliation with the custodian list.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 112, "pagina_pdf_es": 122 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Acuses firmados o electrónicos de los custodios, conciliados con la lista de administradores de llaves que Kyber puede generar.", "evidencia_en": "Signed or electronic custodian acknowledgments, reconciled with the key administrator list Kyber can generate.", "limitaciones": "No verificable por escaneo.", "limitaciones_en": "Not verifiable by scanning.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "6.2", "5.2" ], "soc2_tsc": [ "CC1.4", "CC1.5" ], "cis_controls_v8": [] } }, { "id": 56, "numero_regla": "3.7.9", "requisito": "3", "seccion": "3.7", "categoria": "Requisito 3: Proteger los datos de cuenta almacenados", "categoria_en": "Requirement 3: Protect Stored Account Data", "seccion_titulo": "Procesos de gestión del ciclo de vida de claves criptográficas", "seccion_titulo_en": "Key-management processes covering all aspects of the key lifecycle", "descripcion_corta": "Proveedores de servicio: guía a clientes sobre llaves compartidas", "descripcion_larga": "Requisito adicional solo para proveedores de servicio: cuando el proveedor comparta llaves criptográficas con sus clientes para la transmisión o el almacenamiento de datos de cuenta, debe documentar y entregar a dichos clientes una guía para transmitir, almacenar y actualizar esas llaves de forma segura, conforme a los elementos de los Requisitos 3.7.1 a 3.7.8.", "remediacion": "1) Identifique las llaves que comparte con clientes (p. ej. llaves de cifrado de archivos, llaves de API de cifrado, llaves públicas/privadas de intercambio, acceso entre cuentas a CMK). 2) Redacte una guía que cubra transmisión segura, almacenamiento (KMS/Key Vault/Cloud KMS o HSM), rotación y actualización, retiro y respuesta ante compromiso. 3) Distribuya la guía por un canal controlado y registre la entrega (portal de clientes, contrato, onboarding). 4) Revísela cuando cambie la arquitectura criptográfica. 5) Evidencia: guía publicada y registros de distribución.", "descripcion_corta_en": "Service providers: guidance to customers on shared keys", "descripcion_larga_en": "Additional requirement for service providers only: where the provider shares cryptographic keys with customers for transmitting or storing account data, it must document and distribute to those customers guidance on securely transmitting, storing and updating those keys, consistent with the elements of Requirements 3.7.1 through 3.7.8.", "remediacion_en": "1) Identify keys shared with customers (e.g., file encryption keys, encryption API keys, exchange key pairs, cross-account CMK access). 2) Write guidance covering secure transmission, storage (KMS/Key Vault/Cloud KMS or HSM), rotation and updates, retirement and compromise response. 3) Distribute it through a controlled channel and record delivery (customer portal, contract, onboarding). 4) Review it when the cryptographic architecture changes. 5) Evidence: published guidance and distribution records.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 113, "pagina_pdf_es": 123 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Guía para clientes sobre manejo de llaves compartidas y registros de distribución; Kyber puede generar la plantilla.", "evidencia_en": "Customer guidance on shared key handling and distribution records; Kyber can generate the template.", "limitaciones": "No verificable por escaneo; Kyber solo puede listar CMK compartidas con cuentas externas como insumo.", "limitaciones_en": "Not verifiable by scanning; Kyber can only list CMKs shared with external accounts as input.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.14", "8.24" ], "soc2_tsc": [ "CC2.3", "CC6.1" ], "cis_controls_v8": [] } }, { "id": 57, "numero_regla": "4.1.1", "requisito": "4", "seccion": "4.1", "categoria": "Requisito 4: Proteger los datos de tarjetahabiente con criptografía robusta durante la transmisión por redes públicas abiertas", "categoria_en": "Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks", "seccion_titulo": "Procesos y mecanismos de cifrado en tránsito definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for encryption in transit are defined and understood", "descripcion_corta": "Políticas y procedimientos del Requisito 4 documentados, vigentes, en uso y conocidos", "descripcion_larga": "Las políticas de seguridad y procedimientos operativos del Requisito 4 (protección de datos de titulares con criptografía robusta durante la transmisión por redes públicas abiertas) deben estar documentados, mantenerse actualizados, estar en uso y ser conocidos por todas las partes afectadas. Se recomienda actualizarlos en cuanto ocurra un cambio, no solo en ciclos periódicos.", "remediacion": "1) Redacte una política de cifrado en tránsito que defina protocolos permitidos (TLS 1.2+), suites de cifrado, gestión de certificados (ACM, Key Vault certificates, Certificate Manager) y prohibición de enviar PAN por mensajería de usuario sin cifrado. 2) Documente procedimientos para configurar políticas TLS en ELB/CloudFront/API Gateway, Application Gateway/Front Door y SSL policies de GCP, y para renovar certificados. 3) Asigne dueño, versión y revisión al menos anual y tras cambios. 4) Comunique y registre acuses de lectura. 5) Evidencia: documentos aprobados, historial de versiones y acuses.", "descripcion_corta_en": "Requirement 4 policies and procedures documented, current, in use and known", "descripcion_larga_en": "The security policies and operational procedures for Requirement 4 (protecting cardholder data with strong cryptography during transmission over open, public networks) must be documented, kept up to date, in use and known to all affected parties. Updating them as soon as a change occurs, not only periodically, is recommended.", "remediacion_en": "1) Write an encryption-in-transit policy defining allowed protocols (TLS 1.2+), cipher suites, certificate management (ACM, Key Vault certificates, Certificate Manager) and a ban on sending PAN via unencrypted end-user messaging. 2) Document procedures to configure TLS policies on ELB/CloudFront/API Gateway, Application Gateway/Front Door and GCP SSL policies, and to renew certificates. 3) Assign an owner, version and review at least annually and after changes. 4) Communicate and record read acknowledgments. 5) Evidence: approved documents, version history and acknowledgments.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 115, "pagina_pdf_es": 125 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Política y procedimientos del Requisito 4 aprobados, con historial de versiones y acuses; Kyber puede generar la plantilla.", "evidencia_en": "Approved Requirement 4 policy and procedures with version history and acknowledgments; Kyber can generate the template.", "limitaciones": "El escaneo no puede verificar que las políticas estén en uso ni que el personal las conozca.", "limitaciones_en": "Scanning cannot verify that policies are in use or known by personnel.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.1", "5.37" ], "soc2_tsc": [ "CC5.3", "CC2.2" ], "cis_controls_v8": [ "3.10" ] } }, { "id": 58, "numero_regla": "4.1.2", "requisito": "4", "seccion": "4.1", "categoria": "Requisito 4: Proteger los datos de tarjetahabiente con criptografía robusta durante la transmisión por redes públicas abiertas", "categoria_en": "Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks", "seccion_titulo": "Procesos y mecanismos de cifrado en tránsito definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for encryption in transit are defined and understood", "descripcion_corta": "Roles y responsabilidades del Requisito 4 documentados, asignados y comprendidos", "descripcion_larga": "Las funciones y responsabilidades para ejecutar las actividades del Requisito 4 (configuración de protocolos seguros, gestión de certificados y llaves de transmisión) deben estar documentadas, asignadas y ser comprendidas por las personas responsables. Pueden documentarse en las políticas o por separado, por ejemplo mediante una matriz RACI.", "remediacion": "1) Elabore una matriz RACI para las actividades del Requisito 4: dueño de la política TLS, responsables de configurar balanceadores, CDN y gateways, custodios de certificados y llaves de transmisión, y responsables del inventario de certificados. 2) Relacione cada rol con los roles IAM/RBAC (p. ej. administración de ACM, Key Vault Certificates Officer, Certificate Manager Editor). 3) Obtenga la aceptación de cada responsable. 4) Revise la matriz al menos anualmente. 5) Evidencia: matriz RACI, acuses y entrevistas.", "descripcion_corta_en": "Requirement 4 roles and responsibilities documented, assigned and understood", "descripcion_larga_en": "Roles and responsibilities for performing Requirement 4 activities (secure protocol configuration, certificate and transmission key management) must be documented, assigned and understood by the responsible people. They may be documented within policies or separately, for example via a RACI matrix.", "remediacion_en": "1) Build a RACI matrix for Requirement 4 activities: TLS policy owner, owners of load balancer, CDN and gateway configuration, certificate and transmission key custodians, and certificate inventory owners. 2) Map each role to IAM/RBAC roles (e.g., ACM administration, Key Vault Certificates Officer, Certificate Manager Editor). 3) Obtain acceptance from each owner. 4) Review the matrix at least annually. 5) Evidence: RACI matrix, acknowledgments and interviews.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 116, "pagina_pdf_es": 126 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Matriz RACI del Requisito 4 y acuses de aceptación; Kyber puede generar la plantilla.", "evidencia_en": "Requirement 4 RACI matrix and acknowledgments; Kyber can generate the template.", "limitaciones": "No verificable por escaneo; depende de documentación y entrevistas.", "limitaciones_en": "Not verifiable by scanning; relies on documentation and interviews.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.2", "5.3" ], "soc2_tsc": [ "CC1.3", "CC5.3" ], "cis_controls_v8": [] } }, { "id": 59, "numero_regla": "4.2.1", "requisito": "4", "seccion": "4.2", "categoria": "Requisito 4: Proteger los datos de tarjetahabiente con criptografía robusta durante la transmisión por redes públicas abiertas", "categoria_en": "Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks", "seccion_titulo": "PAN protegido con criptografía robusta durante la transmisión", "seccion_titulo_en": "PAN is protected with strong cryptography during transmission", "descripcion_corta": "Criptografía robusta y protocolos seguros para el PAN en redes públicas abiertas", "descripcion_larga": "Para proteger el PAN durante su transmisión por redes públicas abiertas (Internet y tecnologías inalámbricas como Wi-Fi, Bluetooth, celular y satelital) deben implementarse criptografía robusta y protocolos seguros tales que: solo se acepten llaves y certificados confiables; los certificados usados se confirmen como válidos y no vencidos ni revocados; el protocolo admita solo versiones o configuraciones seguras sin retroceso a versiones, algoritmos, tamaños de llave o implementaciones inseguras; y la fuerza del cifrado sea adecuada a la metodología usada. Un certificado autofirmado puede aceptarse si lo emite una CA interna, se confirma su autor, se verifica (hash o firma) y no ha expirado. El punto de validez de certificados fue mejor práctica hasta el 31 de marzo de 2025.", "remediacion": "1) Exija TLS 1.2 o superior en todos los puntos que reciben o envían PAN: ALB/NLB con políticas ELBSecurityPolicy-TLS13-1-2-2021-06 o equivalentes, CloudFront con MinimumProtocolVersion TLSv1.2_2021, API Gateway con securityPolicy TLS_1_2, Azure Application Gateway con política predefinida AppGwSslPolicy20220101S o superior, Front Door y App Service con minimumTlsVersion 1.2, GCP SSL policies con minTlsVersion TLS_1_2 y perfil MODERN o RESTRICTED. 2) Redirija HTTP a HTTPS y deshabilite suites débiles (CBC con SHA-1, 3DES, RC4). 3) Use certificados de CA confiables gestionados (ACM, Key Vault, Certificate Manager) con renovación automática y RSA ≥ 2048. 4) En conexiones salientes (a adquirentes/gateways) valide certificados y considere pinning. 5) Requiera TLS en bases de datos y almacenamiento accesibles por red pública. 6) Evidencia: configuraciones TLS, resultados de escaneo externo (p. ej. testssl.sh) e inventario de certificados vigentes.", "descripcion_corta_en": "Strong cryptography and secure protocols for PAN over open, public networks", "descripcion_larga_en": "To protect PAN during transmission over open, public networks (the Internet and wireless technologies such as Wi-Fi, Bluetooth, cellular and satellite), strong cryptography and secure protocols must be implemented so that: only trusted keys and certificates are accepted; certificates used are confirmed valid and not expired or revoked; the protocol supports only secure versions or configurations with no fallback to insecure versions, algorithms, key sizes or implementations; and encryption strength suits the methodology used. A self-signed certificate may be acceptable if issued by an internal CA, its author is confirmed, it is verified (hash or signature) and it has not expired. The certificate-validity bullet was a best practice until 31 March 2025.", "remediacion_en": "1) Enforce TLS 1.2 or higher at every point sending or receiving PAN: ALB/NLB with ELBSecurityPolicy-TLS13-1-2-2021-06 or equivalent, CloudFront with MinimumProtocolVersion TLSv1.2_2021, API Gateway securityPolicy TLS_1_2, Azure Application Gateway with predefined policy AppGwSslPolicy20220101S or newer, Front Door and App Service with minimumTlsVersion 1.2, GCP SSL policies with minTlsVersion TLS_1_2 and MODERN or RESTRICTED profile. 2) Redirect HTTP to HTTPS and disable weak suites (CBC with SHA-1, 3DES, RC4). 3) Use managed certificates from trusted CAs (ACM, Key Vault, Certificate Manager) with auto-renewal and RSA ≥ 2048. 4) For outbound connections (to acquirers/gateways) validate certificates and consider pinning. 5) Require TLS on databases and storage reachable over public networks. 6) Evidence: TLS configurations, external scan results (e.g., testssl.sh) and inventory of valid certificates.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 117, "pagina_pdf_es": 127 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Listeners HTTPS/TLS de ALB/NLB con SslPolicy que permite TLS 1.0/1.1 (falla si existe)", "ALB con listener HTTP sin redirección a HTTPS [ELB.1]; Classic LB sin listeners HTTPS/TLS [ELB.3] o con política predefinida débil [ELB.8]", "CloudFront: ViewerProtocolPolicy allow-all [CloudFront.3] o MinimumProtocolVersion inferior a TLSv1.2_2021; protocolos SSL obsoletos hacia orígenes personalizados [CloudFront.10]", "API Gateway: dominios personalizados con securityPolicy TLS_1_0 (falla si existe)", "S3: política de bucket sin denegar aws:SecureTransport = false [S3.5]", "ACM: certificados en uso vencidos o con estado REVOKED/FAILED (falla si existe)" ], "checks_azure": [ "Application Gateway: sslPolicy con minProtocolVersion inferior a TLSv1_2 o política predefinida obsoleta (falla si existe)", "Front Door/CDN: minimumTlsVersion inferior a 1.2 o httpsRedirect deshabilitado (falla si existe)", "App Service/Functions: httpsOnly = false o minTlsVersion < 1.2 (falla si existe)", "Storage Accounts: minimumTlsVersion = TLS1_2 y supportsHttpsTrafficOnly = true", "Azure SQL/PostgreSQL/MySQL: minimalTlsVersion 1.2 y require_secure_transport habilitado", "Key Vault certificates en uso vencidos (falla si existe)" ], "checks_gcp": [ "Target HTTPS/SSL proxies sin SSL policy o con minTlsVersion inferior a TLS_1_2 o perfil COMPATIBLE (falla si existe)", "Cloud SQL: settings.ipConfiguration.sslMode ENCRYPTED_ONLY o TRUSTED_CLIENT_CERTIFICATE_REQUIRED (requireSsl)", "Balanceadores HTTP externos sin redirección a HTTPS para servicios de pago (falla si existe)", "Certificados SSL gestionados/Certificate Manager vencidos o en estado de aprovisionamiento fallido (falla si existe)" ], "evidencia": "Reporte de configuraciones TLS por punto de entrada, inventario de certificados con vigencia y resultado de escaneo externo de protocolos y suites.", "evidencia_en": "TLS configuration report per entry point, certificate inventory with validity and external protocol/cipher scan results.", "limitaciones": "Kyber no observa TLS terminado en aplicaciones dentro de instancias/contenedores ni conexiones salientes de la aplicación hacia terceros, ni la validación de certificados del lado cliente.", "limitaciones_en": "Kyber does not observe TLS terminated inside instances/containers, outbound application connections to third parties, or client-side certificate validation.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "8.20", "5.14" ], "soc2_tsc": [ "CC6.7", "CC6.1" ], "cis_controls_v8": [ "3.10" ], "banxico_spei": [ "58a. I.A.b).1", "58a. I.A.f).9", "58a. I.C.c)" ] }, "mapeo_ucf": [ { "clave": "UCF-CRY-002", "relacion": "equivalent", "cobertura_pct": 90 } ] }, { "id": 60, "numero_regla": "4.2.1.1", "requisito": "4", "seccion": "4.2", "categoria": "Requisito 4: Proteger los datos de tarjetahabiente con criptografía robusta durante la transmisión por redes públicas abiertas", "categoria_en": "Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks", "seccion_titulo": "PAN protegido con criptografía robusta durante la transmisión", "seccion_titulo_en": "PAN is protected with strong cryptography during transmission", "descripcion_corta": "Inventario de llaves y certificados confiables usados para proteger el PAN en tránsito", "descripcion_larga": "La entidad debe mantener un inventario de sus llaves y certificados confiables usados para proteger el PAN durante la transmisión. Este inventario ayuda a conocer algoritmos, protocolos, fuerza de llaves, custodios y fechas de expiración, para responder con rapidez a vulnerabilidades en software de cifrado, certificados o algoritmos; para certificados conviene incluir la CA emisora y la fecha de vencimiento. Fue mejor práctica hasta el 31 de marzo de 2025.", "remediacion": "1) Genere el inventario desde los servicios de certificados: AWS Certificate Manager y ACM Private CA, IAM server certificates, Azure Key Vault certificates y certificados de App Service/Application Gateway, GCP Certificate Manager y SSL certificates de Compute. 2) Incluya por cada elemento: dominio/uso, CA emisora, algoritmo y tamaño de llave, fecha de vencimiento, custodio y recurso asociado. 3) Agregue llaves y certificados fuera de la nube (HSM de pago, VPN con adquirentes, certificados en aplicaciones). 4) Configure alertas de vencimiento (ACM DaysToExpiry en EventBridge, Key Vault lifetimeActions EmailContacts/AutoRenew, Cloud Monitoring). 5) Actualice el inventario de forma continua y revíselo al menos trimestralmente. 6) Evidencia: inventario vigente y procedimiento.", "descripcion_corta_en": "Inventory of trusted keys and certificates used to protect PAN in transit", "descripcion_larga_en": "The entity must maintain an inventory of its trusted keys and certificates used to protect PAN during transmission. The inventory helps track algorithms, protocols, key strength, custodians and expiry dates so the entity can respond quickly to vulnerabilities in encryption software, certificates or algorithms; for certificates it should include the issuing CA and expiration date. It was a best practice until 31 March 2025.", "remediacion_en": "1) Generate the inventory from certificate services: AWS Certificate Manager and ACM Private CA, IAM server certificates, Azure Key Vault certificates and App Service/Application Gateway certificates, GCP Certificate Manager and Compute SSL certificates. 2) Record for each item: domain/use, issuing CA, algorithm and key size, expiry date, custodian and associated resource. 3) Add keys and certificates outside the cloud (payment HSMs, VPNs with acquirers, in-application certificates). 4) Configure expiry alerts (ACM DaysToExpiry via EventBridge, Key Vault lifetimeActions EmailContacts/AutoRenew, Cloud Monitoring). 5) Keep the inventory continuously updated and review it at least quarterly. 6) Evidence: current inventory and procedure.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 120, "pagina_pdf_es": 130 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Inventario de ACM (DomainName, Issuer, KeyAlgorithm, NotAfter, InUseBy) e IAM server certificates", "Certificados ACM RSA con llave menor a 2048 bits [ACM.2]", "Certificados ACM próximos a vencer o sin renovación (falla si NotAfter dentro del umbral) [ACM.1]", "IAM server certificates vencidos aún cargados (falla si existe)" ], "checks_azure": [ "Inventario de Key Vault certificates (issuer, keyProperties, expires) y certificados de App Service/Application Gateway", "Key Vault certificates sin lifetimeAction AutoRenew o EmailContacts (falla si existe)", "Certificados con validez mayor a la política o próximos a vencer (falla si existe)" ], "checks_gcp": [ "Inventario de Certificate Manager y Compute SSL certificates (dominios, emisor, expireTime)", "Certificados autogestionados (self-managed) próximos a vencer (falla si expireTime dentro del umbral)" ], "evidencia": "Inventario de certificados y llaves de transmisión generado por Kyber, complementado con elementos fuera de la nube y custodios asignados.", "evidencia_en": "Inventory of transmission certificates and keys generated by Kyber, complemented with off-cloud items and assigned custodians.", "limitaciones": "No incluye certificados instalados dentro de instancias, contenedores, aplicaciones ni equipos on-prem; el custodio debe aportarlo el cliente.", "limitaciones_en": "Does not include certificates installed inside instances, containers, applications or on-prem devices; custodian data must come from the customer.", "responsabilidad_compartida": "compartida", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "5.9" ], "soc2_tsc": [ "CC6.7", "CC6.1" ], "cis_controls_v8": [ "3.10", "1.1" ], "banxico_spei": [ "58a. I.A.c).3" ] } }, { "id": 61, "numero_regla": "4.2.2", "requisito": "4", "seccion": "4.2", "categoria": "Requisito 4: Proteger los datos de tarjetahabiente con criptografía robusta durante la transmisión por redes públicas abiertas", "categoria_en": "Requirement 4: Protect Cardholder Data with Strong Cryptography During Transmission Over Open, Public Networks", "seccion_titulo": "PAN protegido con criptografía robusta durante la transmisión", "seccion_titulo_en": "PAN is protected with strong cryptography during transmission", "descripcion_corta": "PAN protegido con criptografía robusta al enviarse por mensajería de usuario final", "descripcion_larga": "Siempre que el PAN se envíe mediante tecnologías de mensajería de usuario final (correo electrónico, mensajería instantánea, SMS, chat) debe protegerse con criptografía robusta. Aplica también cuando un cliente u otro tercero solicita recibir el PAN por esos medios. Si se recibe PAN no solicitado por un canal inseguro no destinado a datos sensibles, la entidad puede incluir el canal en el alcance del CDE y protegerlo según PCI DSS, o eliminar los datos e impedir que el canal se use para ello.", "remediacion": "1) Prohíba en la política de uso aceptable el envío de PAN por mensajería salvo necesidad definida. 2) Cuando sea necesario, use cifrado de extremo a extremo a nivel de mensaje (S/MIME, PGP, cifrado de mensajes de Microsoft Purview, Gmail S/MIME) y no solo TLS oportunista. 3) En correo transaccional desde la nube configure TLS obligatorio (Amazon SES configuration set TlsPolicy = REQUIRE) y evite incluir PAN completo. 4) Implemente DLP de correo y chat (Microsoft Purview DLP para Exchange/Teams, reglas DLP de Google Workspace) que bloqueen o cifren mensajes con PAN. 5) Defina el procedimiento para PAN recibido por canales no autorizados (borrado seguro y respuesta al remitente). 6) Evidencia: política, configuración de DLP/cifrado y procedimiento.", "descripcion_corta_en": "PAN secured with strong cryptography when sent via end-user messaging", "descripcion_larga_en": "Whenever PAN is sent via end-user messaging technologies (email, instant messaging, SMS, chat) it must be secured with strong cryptography. This also applies when a customer or other third party asks to receive PAN through those channels. If unsolicited PAN arrives over an insecure channel not intended for sensitive data, the entity may bring the channel into CDE scope and secure it per PCI DSS, or delete the data and prevent the channel from being used for it.", "remediacion_en": "1) Prohibit sending PAN by messaging in the acceptable use policy unless there is a defined need. 2) Where needed, use message-level end-to-end encryption (S/MIME, PGP, Microsoft Purview Message Encryption, Gmail S/MIME), not just opportunistic TLS. 3) For transactional email from the cloud enforce TLS (Amazon SES configuration set TlsPolicy = REQUIRE) and avoid including full PAN. 4) Deploy email and chat DLP (Microsoft Purview DLP for Exchange/Teams, Google Workspace DLP rules) that blocks or encrypts messages with PAN. 5) Define the procedure for PAN received over unauthorized channels (secure deletion and reply to sender). 6) Evidence: policy, DLP/encryption configuration and procedure.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 122, "pagina_pdf_es": 132 }, "kyber_cobertura": { "tipo": "fuera_alcance_agentless", "automatizacion": "baja", "checks_aws": [ "Amazon SES: configuration sets con DeliveryOptions.TlsPolicy = OPTIONAL usados para correo con datos de cuenta (falla si existe)" ], "checks_azure": [], "checks_gcp": [], "evidencia": "Política de uso aceptable, configuración de DLP y cifrado de mensajería (Purview/Workspace) aportada por el cliente y procedimiento para PAN recibido por canales no autorizados.", "evidencia_en": "Acceptable use policy, messaging DLP and encryption configuration (Purview/Workspace) provided by the customer, and procedure for PAN received through unauthorized channels.", "limitaciones": "Correo, chat y SMS viven en plataformas SaaS y endpoints fuera del escaneo agentless de infraestructura; solo se evalúa el correo saliente de SES.", "limitaciones_en": "Email, chat and SMS live in SaaS platforms and endpoints outside agentless infrastructure scanning; only SES outbound email is evaluated.", "responsabilidad_compartida": "cliente", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.14", "8.24", "8.12" ], "soc2_tsc": [ "CC6.7" ], "cis_controls_v8": [ "3.10", "3.13" ] } }, { "id": 62, "numero_regla": "5.1.1", "requisito": "5", "seccion": "5.1", "categoria": "Requisito 5: Proteger todos los sistemas y redes contra software malicioso", "categoria_en": "Requirement 5: Protect All Systems and Networks from Malicious Software", "seccion_titulo": "Procesos y mecanismos contra software malicioso definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for malware protection are defined and understood", "descripcion_corta": "Políticas y procedimientos operativos del Requisito 5 (protección contra malware) gestionados", "descripcion_larga": "Las políticas de seguridad y los procedimientos operativos que respaldan la protección de sistemas y redes contra software malicioso (Requisito 5) deben estar documentados, mantenerse vigentes, aplicarse en la práctica y ser conocidos por todas las partes involucradas. El objetivo es que las expectativas, controles y supervisión de estas actividades estén definidos, se ejecuten de forma repetible y consistente, y reflejen la intención de la dirección.", "remediacion": "1. Redacte una política antimalware que cubra alcance (cómputo, contenedores, almacenamiento de objetos), herramientas aprobadas (p. ej. Amazon GuardDuty Malware Protection, Microsoft Defender for Servers/Storage, GCP Security Command Center), actualizaciones, escaneos, bitácoras y excepciones. 2. Documente procedimientos operativos: habilitación por cuenta/suscripción/proyecto, atención de hallazgos, solicitud de deshabilitación temporal y evaluación de sistemas no en riesgo. 3. Asigne un dueño y revísela al menos una vez cada 12 meses y tras cambios relevantes, con control de versiones. 4. Publíquela en un repositorio accesible y obtenga acuse de lectura del personal afectado. Evidencia para el QSA: documento vigente con historial de versiones, fecha de última revisión y registros de difusión o acuse.", "descripcion_corta_en": "Requirement 5 (malware protection) security policies and operational procedures are managed", "descripcion_larga_en": "Security policies and operational procedures that support protecting systems and networks from malicious software (Requirement 5) must be documented, kept current, actually used, and known to every affected party. The aim is that expectations, controls and oversight for these activities are defined, performed repeatably and consistently, and reflect management's intent.", "remediacion_en": "1. Write an anti-malware policy covering scope (compute, containers, object storage), approved tools (e.g., Amazon GuardDuty Malware Protection, Microsoft Defender for Servers/Storage, GCP Security Command Center), updates, scans, logging and exceptions. 2. Document operating procedures: enablement per account/subscription/project, finding handling, temporary-disable requests and evaluation of systems not at risk. 3. Assign an owner and review at least every 12 months and after relevant changes, under version control. 4. Publish it in an accessible repository and collect read acknowledgments from affected staff. QSA evidence: current document with version history, last review date and dissemination or acknowledgment records.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 124, "pagina_pdf_es": 134 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Política y procedimientos antimalware aprobados, con historial de versiones, fecha de revisión y acuses de lectura; Kyber puede generar una plantilla mediante su generador de políticas.", "evidencia_en": "Approved anti-malware policy and procedures with version history, review date and read acknowledgments; Kyber can produce a template through its policy generator.", "limitaciones": "El escaneo no puede verificar que las políticas estén en uso ni que el personal las conozca.", "limitaciones_en": "Scanning cannot verify that policies are in use or known to personnel.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.1", "5.37", "8.7" ], "soc2_tsc": [ "CC2.2", "CC5.3" ], "cis_controls_v8": [] } }, { "id": 63, "numero_regla": "5.1.2", "requisito": "5", "seccion": "5.1", "categoria": "Requisito 5: Proteger todos los sistemas y redes contra software malicioso", "categoria_en": "Requirement 5: Protect All Systems and Networks from Malicious Software", "seccion_titulo": "Procesos y mecanismos contra software malicioso definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for malware protection are defined and understood", "descripcion_corta": "Roles y responsabilidades del Requisito 5 documentados, asignados y comprendidos", "descripcion_larga": "Las funciones y responsabilidades para ejecutar las actividades del Requisito 5 (protección contra malware) deben estar documentadas, asignadas a personas concretas y ser comprendidas por ellas. Así, la operación diaria de estos controles queda repartida y el personal responde por su funcionamiento continuo y exitoso. Pueden documentarse dentro de las políticas o en documentos separados, por ejemplo una matriz RACI.", "remediacion": "1. Elabore una matriz RACI para las actividades antimalware: habilitar y mantener GuardDuty/Defender/SCC, revisar hallazgos, gestionar excepciones, evaluar sistemas no en riesgo y conservar bitácoras. 2. Asigne nombres o puestos concretos, incluyendo responsables en cada cuenta AWS, suscripción Azure y proyecto GCP. 3. Comunique la matriz y obtenga acuse de aceptación de cada responsable. 4. Revísela cada 12 meses o ante cambios de personal o de organización. Evidencia para el QSA: matriz RACI vigente, descripciones de puesto y acuses firmados; entrevistas al personal que confirmen que conoce su rol.", "descripcion_corta_en": "Requirement 5 roles and responsibilities are documented, assigned and understood", "descripcion_larga_en": "Roles and responsibilities for carrying out Requirement 5 (malware protection) activities must be documented, assigned to specific people, and understood by them. This ensures daily operation of these controls is allocated and personnel are accountable for their successful, continuous operation. They may be documented in policies or separate documents, such as a RACI matrix.", "remediacion_en": "1. Build a RACI matrix for anti-malware activities: enabling and maintaining GuardDuty/Defender/SCC, reviewing findings, handling exceptions, evaluating systems not at risk and retaining logs. 2. Name specific people or positions, including owners for each AWS account, Azure subscription and GCP project. 3. Communicate the matrix and collect acceptance acknowledgments from each owner. 4. Review it every 12 months or upon staff or organizational changes. QSA evidence: current RACI matrix, job descriptions and signed acknowledgments; interviews confirming personnel understand their role.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 125, "pagina_pdf_es": 135 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Matriz RACI y acuses de aceptación cargados por el cliente; Kyber puede generar la plantilla de roles.", "evidencia_en": "RACI matrix and acceptance acknowledgments uploaded by the customer; Kyber can generate the roles template.", "limitaciones": "No es verificable mediante escaneo de nube; requiere entrevistas.", "limitaciones_en": "Not verifiable through cloud scanning; requires interviews.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.2", "5.3" ], "soc2_tsc": [ "CC1.3", "CC5.3" ], "cis_controls_v8": [] } }, { "id": 64, "numero_regla": "5.2.1", "requisito": "5", "seccion": "5.2", "categoria": "Requisito 5: Proteger todos los sistemas y redes contra software malicioso", "categoria_en": "Requirement 5: Protect All Systems and Networks from Malicious Software", "seccion_titulo": "Malware prevenido, o detectado y atendido", "seccion_titulo_en": "Malware is prevented, or detected and addressed", "descripcion_corta": "Solución antimalware desplegada en todos los componentes del sistema en riesgo", "descripcion_larga": "Se debe desplegar una o varias soluciones antimalware en todos los componentes del sistema. Solo pueden quedar fuera aquellos componentes que, mediante las evaluaciones periódicas del Requisito 5.2.3, se haya concluido que no están en riesgo de malware. El propósito es contar con mecanismos automatizados que impidan que los sistemas se conviertan en vector de ataque; para los componentes sin solución deben existir evaluaciones documentadas que justifiquen la exclusión.", "remediacion": "1. AWS: habilite Amazon GuardDuty en todas las cuentas y regiones mediante administrador delegado de AWS Organizations, active Malware Protection for EC2 (escaneo de volúmenes EBS), Runtime Monitoring para EC2/EKS/ECS y Malware Protection for S3 en buckets que reciban cargas externas. 2. Azure: active Microsoft Defender for Servers (Plan 1 o 2) en cada suscripción con integración de Microsoft Defender for Endpoint, y Defender for Storage con escaneo de malware al cargar. 3. GCP: habilite Security Command Center (Premium/Enterprise) a nivel organización con VM Threat Detection y Container Threat Detection, y despliegue un EDR en las VM. 4. Use Azure Policy, SCP/AWS Config y restricciones de organización para auto-habilitar la protección en recursos nuevos. 5. Conserve la lista de componentes excluidos con su evaluación de riesgo (5.2.3). Evidencia: reportes de cobertura por cuenta/suscripción/proyecto, configuración de los planes y lista de excepciones conciliada.", "descripcion_corta_en": "Anti-malware solution deployed on all system components at risk", "descripcion_larga_en": "One or more anti-malware solutions must be deployed on all system components. Only components that periodic evaluations under Requirement 5.2.3 conclude are not at risk from malware may be excluded. The goal is automated mechanisms that prevent systems from becoming a malware attack vector; any component without a solution must have a documented evaluation justifying the exclusion.", "remediacion_en": "1. AWS: enable Amazon GuardDuty in all accounts and regions through an AWS Organizations delegated administrator, turn on Malware Protection for EC2 (EBS volume scanning), Runtime Monitoring for EC2/EKS/ECS, and Malware Protection for S3 on buckets receiving external uploads. 2. Azure: enable Microsoft Defender for Servers (Plan 1 or 2) on every subscription with Microsoft Defender for Endpoint integration, and Defender for Storage with on-upload malware scanning. 3. GCP: enable Security Command Center (Premium/Enterprise) at the organization level with VM Threat Detection and Container Threat Detection, and deploy an EDR on VMs. 4. Use Azure Policy, SCPs/AWS Config and organization policies to auto-enable protection on new resources. 5. Keep the list of excluded components with their risk evaluation (5.2.3). Evidence: coverage reports per account/subscription/project, plan configuration and a reconciled exception list.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 126, "pagina_pdf_es": 136 }, "kyber_cobertura": { "tipo": "deteccion_presencia", "automatizacion": "media", "checks_aws": [ "GuardDuty habilitado en todas las cuentas y regiones activas (falla si algún detector falta o está suspendido) [GuardDuty.1]", "GuardDuty Malware Protection for EC2 (EBS_MALWARE_PROTECTION) habilitado en el detector (falla si está deshabilitado)", "GuardDuty Runtime Monitoring habilitado con gestión automática de agente para EC2/EKS/ECS (falla si no cubre las instancias o clústeres del CDE)", "Buckets S3 que reciben cargas externas sin plan de GuardDuty Malware Protection for S3 (falla si existe)", "Instancias EC2 en el CDE sin cobertura de GuardDuty ni EDR identificable en el snapshot (falla si existe y no está en la lista de excepciones)" ], "checks_azure": [ "Microsoft Defender for Servers: pricings VirtualMachines con pricingTier = Standard en cada suscripción (falla si Free)", "Extensión MDE.Windows/MDE.Linux aprovisionada y en estado correcto en las VM y servidores Arc del CDE", "Defender for Storage habilitado con onUploadMalwareScanning = true en cuentas de almacenamiento que reciben cargas", "VM sin agente o extensión antimalware detectada en el snapshot y no listada como excepción (falla si existe)" ], "checks_gcp": [ "Security Command Center Premium/Enterprise activo a nivel organización (falla si solo Standard o desactivado)", "VM Threat Detection y Container Threat Detection habilitados (falla si algún servicio está deshabilitado)", "VM de Compute Engine en el CDE sin EDR/antimalware identificable en el snapshot (falla si existe sin excepción)" ], "evidencia": "Kyber genera el reporte de cobertura antimalware por recurso y la lista de componentes sin protección para conciliar con las excepciones del 5.2.3.", "evidencia_en": "Kyber produces the per-resource anti-malware coverage report and the list of unprotected components to reconcile against 5.2.3 exceptions.", "limitaciones": "Se verifica la presencia y activación de la herramienta, no su eficacia de detección; no cubre estaciones de trabajo ni equipos on-premises.", "limitaciones_en": "Tool presence and activation are verified, not detection efficacy; workstations and on-premises devices are not covered.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.7" ], "soc2_tsc": [ "CC6.8" ], "cis_controls_v8": [ "10.1", "10.6" ], "banxico_spei": [ "58a. I.A.b).2", "58a. I.B.f)" ] }, "mapeo_ucf": [ { "clave": "UCF-MAL-001", "relacion": "equivalent", "cobertura_pct": 100 } ] }, { "id": 65, "numero_regla": "5.2.2", "requisito": "5", "seccion": "5.2", "categoria": "Requisito 5: Proteger todos los sistemas y redes contra software malicioso", "categoria_en": "Requirement 5: Protect All Systems and Networks from Malicious Software", "seccion_titulo": "Malware prevenido, o detectado y atendido", "seccion_titulo_en": "Malware is prevented, or detected and addressed", "descripcion_corta": "Antimalware que detecta y elimina, bloquea o contiene todos los tipos conocidos de malware", "descripcion_larga": "La solución antimalware desplegada debe ser capaz de detectar todos los tipos conocidos de malware y de eliminarlos, bloquearlos o contenerlos. Entre los tipos de malware se encuentran virus, troyanos, gusanos, spyware, ransomware, keyloggers, rootkits, código malicioso, scripts y enlaces. El objetivo es que el malware no pueda ejecutarse ni infectar otros componentes del sistema.", "remediacion": "1. Elija soluciones con capacidad de detección y respuesta: Microsoft Defender for Endpoint (protección en tiempo real y remediación automática), GuardDuty Runtime Monitoring junto con un EDR en EC2, o un EDR en VM de GCP; el escaneo agentless de GuardDuty Malware Protection solo detecta, por lo que debe complementarse con una acción de contención. 2. Configure respuesta automática: en Defender for Endpoint, modo de remediación automatizada completa; en AWS, reglas de EventBridge sobre hallazgos de malware que aíslen la instancia (cambio de security group de cuarentena) o pongan en cuarentena el objeto S3 con etiquetado y política de bucket; en GCP, Pub/Sub de SCC con Cloud Functions de aislamiento. 3. Para S3/Blob, bloquee el acceso a objetos marcados como infectados. 4. Conserve la documentación del fabricante que acredite cobertura de tipos de malware. Evidencia: documentación del fabricante, configuración de respuesta automática y ejemplos de hallazgos contenidos.", "descripcion_corta_en": "Anti-malware detects and removes, blocks or contains all known malware types", "descripcion_larga_en": "The deployed anti-malware solution must be able to detect all known types of malware and to remove, block or contain them. Malware types include viruses, Trojans, worms, spyware, ransomware, keyloggers, rootkits, malicious code, scripts and links. The objective is that malware cannot execute or infect other system components.", "remediacion_en": "1. Choose solutions with detection and response capabilities: Microsoft Defender for Endpoint (real-time protection and automated remediation), GuardDuty Runtime Monitoring together with an EDR on EC2, or an EDR on GCP VMs; GuardDuty's agentless Malware Protection scan only detects, so pair it with a containment action. 2. Configure automated response: in Defender for Endpoint, full automated remediation mode; in AWS, EventBridge rules on malware findings that isolate the instance (quarantine security group) or quarantine the S3 object via tagging and bucket policy; in GCP, SCC Pub/Sub notifications with isolating Cloud Functions. 3. For S3/Blob, block access to objects tagged as infected. 4. Keep vendor documentation showing malware type coverage. Evidence: vendor documentation, automated response configuration and examples of contained findings.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 127, "pagina_pdf_es": 137 }, "kyber_cobertura": { "tipo": "deteccion_presencia", "automatizacion": "media", "checks_aws": [ "Regla de EventBridge que consume hallazgos de GuardDuty de tipo Execution:EC2/MaliciousFile y Object:S3/MaliciousFile con acción de contención (falla si no existe)", "GuardDuty Malware Protection for S3 con etiquetado de objetos habilitado y política de bucket que niegue acceso a objetos etiquetados como amenaza", "Instancias del CDE con agente EDR capaz de bloqueo/remediación detectado en el snapshot (falla si solo hay escaneo agentless)" ], "checks_azure": [ "Defender for Endpoint: automatización de investigación y remediación en modo completo para los grupos de dispositivos del CDE", "Protección en tiempo real de Microsoft Defender Antivirus activa (realTimeProtection habilitado) según la evaluación de Defender for Cloud", "Defender for Storage: respuesta configurada para blobs maliciosos (soft delete/cuarentena vía Event Grid)" ], "checks_gcp": [ "Notificaciones de SCC hacia Pub/Sub con automatización de contención para hallazgos de malware (falla si no existe)", "EDR con capacidad de bloqueo detectado en las VM del CDE a partir del snapshot" ], "evidencia": "Configuración de respuesta automática, documentación del fabricante y ejemplos de hallazgos remediados; Kyber reporta la presencia de agentes y automatizaciones.", "evidencia_en": "Automated response configuration, vendor documentation and examples of remediated findings; Kyber reports the presence of agents and automations.", "limitaciones": "El escaneo no puede comprobar que se detecten todos los tipos de malware ni la efectividad del bloqueo.", "limitaciones_en": "Scanning cannot prove that all malware types are detected or that blocking is effective.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.7" ], "soc2_tsc": [ "CC6.8", "CC7.2" ], "cis_controls_v8": [ "10.1", "10.7" ], "banxico_spei": [ "58a. I.A.b).2" ] } }, { "id": 66, "numero_regla": "5.2.3", "requisito": "5", "seccion": "5.2", "categoria": "Requisito 5: Proteger todos los sistemas y redes contra software malicioso", "categoria_en": "Requirement 5: Protect All Systems and Networks from Malicious Software", "seccion_titulo": "Malware prevenido, o detectado y atendido", "seccion_titulo_en": "Malware is prevented, or detected and addressed", "descripcion_corta": "Evaluación periódica de componentes considerados sin riesgo de malware", "descripcion_larga": "Los componentes del sistema que se consideren no expuestos a malware deben evaluarse periódicamente. La evaluación incluye una lista documentada de dichos componentes, la identificación y análisis de amenazas de malware emergentes que puedan afectarlos y la confirmación de si siguen sin requerir protección antimalware. Aplica únicamente a los componentes en los que no se despliega solución antimalware conforme al Requisito 5.2.1.", "remediacion": "1. Mantenga un inventario de componentes excluidos de antimalware (p. ej. appliances, bases de datos administradas, sistemas mainframe) con la justificación de cada exclusión. 2. En cada evaluación revise alertas del fabricante, boletines de CERT y foros de amenazas para detectar malware nuevo dirigido a esos tipos de sistema. 3. Documente la conclusión por tipo de sistema y, si cambia el riesgo, defina un plan para incorporar protección (p. ej. habilitar GuardDuty Runtime Monitoring o Defender for Servers). 4. Concilie la lista con el reporte de cobertura de Kyber para que coincidan los componentes sin antimalware. Evidencia: lista vigente, actas de evaluación con fecha y conclusiones, y conciliación con 5.2.1.", "descripcion_corta_en": "Periodic evaluation of system components deemed not at risk from malware", "descripcion_larga_en": "System components considered not at risk from malware must be evaluated periodically. The evaluation includes a documented list of those components, identification and assessment of evolving malware threats that could affect them, and confirmation of whether they still do not require anti-malware protection. It applies only to components with no anti-malware solution deployed under Requirement 5.2.1.", "remediacion_en": "1. Maintain an inventory of components excluded from anti-malware (e.g., appliances, managed databases, mainframe systems) with the justification for each exclusion. 2. At each evaluation review vendor alerts, CERT bulletins and threat forums for new malware targeting those system types. 3. Document the conclusion per system type and, if risk changes, define a plan to add protection (e.g., enable GuardDuty Runtime Monitoring or Defender for Servers). 4. Reconcile the list with Kyber's coverage report so the components without anti-malware match. Evidence: current list, dated evaluation records with conclusions, and reconciliation with 5.2.1.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 128, "pagina_pdf_es": 138 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Listado de instancias EC2, tareas ECS y funciones Lambda del CDE sin GuardDuty Malware Protection/Runtime Monitoring ni EDR (insumo para la lista de excepciones)" ], "checks_azure": [ "Listado de VM y servidores Arc sin Defender for Servers ni extensión MDE (insumo para la lista de excepciones)" ], "checks_gcp": [ "Listado de VM y clústeres GKE sin cobertura de SCC/VM Threat Detection ni EDR (insumo para la lista de excepciones)" ], "evidencia": "Kyber genera la lista de componentes sin antimalware para conciliar; el cliente aporta la evaluación de amenazas y la conclusión documentada.", "evidencia_en": "Kyber generates the list of components without anti-malware for reconciliation; the customer provides the threat evaluation and documented conclusion.", "limitaciones": "Kyber no puede evaluar la evolución de amenazas ni validar la justificación de cada exclusión.", "limitaciones_en": "Kyber cannot assess evolving threats or validate the justification of each exclusion.", "responsabilidad_compartida": "cliente", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.7", "5.7" ], "soc2_tsc": [ "CC6.8", "CC3.2" ], "cis_controls_v8": [ "10.1", "1.1" ] } }, { "id": 67, "numero_regla": "5.2.3.1", "requisito": "5", "seccion": "5.2", "categoria": "Requisito 5: Proteger todos los sistemas y redes contra software malicioso", "categoria_en": "Requirement 5: Protect All Systems and Networks from Malicious Software", "seccion_titulo": "Malware prevenido, o detectado y atendido", "seccion_titulo_en": "Malware is prevented, or detected and addressed", "descripcion_corta": "Frecuencia de evaluación de componentes sin riesgo de malware definida por análisis de riesgo específico", "descripcion_larga": "La periodicidad con la que se reevalúan los componentes identificados como no expuestos a malware debe fijarse en un análisis de riesgo específico de la entidad, elaborado conforme a todos los elementos del Requisito 12.3.1. Las evaluaciones deben realizarse con la frecuencia que dicho análisis determine. Era una mejor práctica hasta el 31 de marzo de 2025 y desde entonces es obligatorio.", "remediacion": "1. Elabore un análisis de riesgo específico (TRA) según 12.3.1 que considere la complejidad del entorno, la cantidad de tipos de sistema excluidos y la exposición a Internet. 2. Defina la frecuencia resultante (p. ej. trimestral o semestral) y regístrela en la política antimalware. 3. Programe las evaluaciones en una herramienta de tickets con recordatorios y responsables. 4. Revise el TRA al menos cada 12 meses. Evidencia: TRA aprobado, calendario y registros de evaluaciones realizadas en la frecuencia definida.", "descripcion_corta_en": "Frequency of evaluating components not at risk from malware set by a targeted risk analysis", "descripcion_larga_en": "How often components identified as not at risk from malware are re-evaluated must be set in the entity's targeted risk analysis, performed according to all elements of Requirement 12.3.1. Evaluations must be performed at the frequency that analysis determines. This was a best practice until 31 March 2025 and is now mandatory.", "remediacion_en": "1. Perform a targeted risk analysis (TRA) per 12.3.1 considering environment complexity, the number of excluded system types and Internet exposure. 2. Define the resulting frequency (e.g., quarterly or semi-annually) and record it in the anti-malware policy. 3. Schedule evaluations in a ticketing tool with reminders and owners. 4. Review the TRA at least every 12 months. Evidence: approved TRA, schedule and records of evaluations performed at the defined frequency.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 129, "pagina_pdf_es": 139 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "TRA aprobado y registros de evaluaciones con fecha cargados por el cliente; Kyber puede generar la plantilla de TRA.", "evidencia_en": "Approved TRA and dated evaluation records uploaded by the customer; Kyber can generate the TRA template.", "limitaciones": "No hay componente técnico verificable por escaneo.", "limitaciones_en": "No technical component verifiable by scanning.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.7", "8.7" ], "soc2_tsc": [ "CC3.2" ], "cis_controls_v8": [ "10.1" ] } }, { "id": 68, "numero_regla": "5.3.1", "requisito": "5", "seccion": "5.3", "categoria": "Requisito 5: Proteger todos los sistemas y redes contra software malicioso", "categoria_en": "Requirement 5: Protect All Systems and Networks from Malicious Software", "seccion_titulo": "Mecanismos anti-malware activos, mantenidos y monitoreados", "seccion_titulo_en": "Anti-malware mechanisms are active, maintained, and monitored", "descripcion_corta": "Solución antimalware actualizada mediante actualizaciones automáticas", "descripcion_larga": "La solución antimalware debe mantenerse al día mediante actualizaciones automáticas, de modo que sus firmas, motores de análisis y demás protecciones puedan detectar las amenazas más recientes. Las configuraciones, incluida cualquier instalación maestra, deben estar preparadas para actualizarse solas, y las definiciones deben desplegarse con prontitud en los componentes.", "remediacion": "1. En servicios administrados (GuardDuty, Defender for Storage, SCC) las firmas las actualiza el proveedor; documente esta herencia con sus reportes de cumplimiento. 2. Para agentes en VM (Defender for Endpoint, EDR de terceros) habilite actualizaciones automáticas de motor y firmas y, si usa repositorio central, distribúyalas desde una fuente confiable. 3. Monitoree la antigüedad de firmas: Defender for Cloud recomienda actualizar firmas en máquinas con definiciones desactualizadas; use AWS Systems Manager o Azure Update Manager para mantener la versión del agente. 4. Alerte cuando las firmas superen un umbral (p. ej. más de 3 días). Evidencia: configuración de actualización automática, reporte de versiones de firmas por equipo y bitácoras de actualización.", "descripcion_corta_en": "Anti-malware solution kept current through automatic updates", "descripcion_larga_en": "The anti-malware solution must be kept current through automatic updates so its signatures, analysis engines and other protections can detect the latest threats. Configurations, including any master installation, must be set to update automatically, and definitions must be promptly deployed to system components.", "remediacion_en": "1. For managed services (GuardDuty, Defender for Storage, SCC) the provider updates signatures; document this inheritance with their compliance reports. 2. For VM agents (Defender for Endpoint, third-party EDR) enable automatic engine and signature updates and, if a central repository is used, distribute from a trusted source. 3. Monitor signature age: Defender for Cloud flags machines with outdated definitions; use AWS Systems Manager or Azure Update Manager to keep agent versions current. 4. Alert when signatures exceed a threshold (e.g., older than 3 days). Evidence: automatic update configuration, per-host signature version report and update logs.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 130, "pagina_pdf_es": 140 }, "kyber_cobertura": { "tipo": "deteccion_presencia", "automatizacion": "media", "checks_aws": [ "GuardDuty Runtime Monitoring con gestión automática del agente (EnableAutomatedAgentManagement / AUTO_MANAGED) habilitada", "Instancias EC2 cuyo snapshot muestra firmas antimalware con más de 7 días de antigüedad (falla si existe)", "Asociación de AWS Systems Manager State Manager o Distributor que mantiene actualizado el agente EDR en las instancias del CDE" ], "checks_azure": [ "Defender for Cloud: recomendación de firmas antimalware desactualizadas sin máquinas no saludables en el CDE", "Extensión MDE con actualización automática de versión (enableAutomaticUpgrade = true)" ], "checks_gcp": [ "VM cuyo snapshot muestra definiciones del agente antimalware con más de 7 días de antigüedad (falla si existe)", "VM Manager con política de OS policy assignment que mantiene el agente EDR actualizado" ], "evidencia": "Reporte de Kyber con la antigüedad de firmas por recurso y configuración de actualización automática; reportes del proveedor para servicios administrados.", "evidencia_en": "Kyber report of signature age per resource and auto-update configuration; provider reports for managed services.", "limitaciones": "La detección de antigüedad de firmas depende de que el agente sea reconocible en el snapshot; no confirma la integridad de la fuente de actualización.", "limitaciones_en": "Signature age detection depends on the agent being recognizable in the snapshot; it does not confirm the integrity of the update source.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.7", "8.8" ], "soc2_tsc": [ "CC6.8" ], "cis_controls_v8": [ "10.2" ], "banxico_spei": [ "58a. I.A.b).2", "58a. I.B.f)" ] } }, { "id": 69, "numero_regla": "5.3.2", "requisito": "5", "seccion": "5.3", "categoria": "Requisito 5: Proteger todos los sistemas y redes contra software malicioso", "categoria_en": "Requirement 5: Protect All Systems and Networks from Malicious Software", "seccion_titulo": "Mecanismos anti-malware activos, mantenidos y monitoreados", "seccion_titulo_en": "Anti-malware mechanisms are active, maintained, and monitored", "descripcion_corta": "Antimalware con escaneos periódicos y en tiempo real, o análisis continuo de comportamiento", "descripcion_larga": "La solución antimalware debe cumplir al menos una de dos modalidades: realizar escaneos periódicos junto con escaneo activo o en tiempo real, o bien efectuar un análisis continuo del comportamiento de sistemas o procesos. Debe estar habilitada en todos los tipos de sistema operativo identificados como en riesgo, y las bitácoras y resultados deben demostrarlo. El objetivo es impedir que el malware complete su ejecución.", "remediacion": "1. Opción de comportamiento continuo: habilite GuardDuty Runtime Monitoring en EC2, EKS y ECS/Fargate; Defender for Endpoint con protección en tiempo real y EDR en modo bloqueo en Azure; VM Threat Detection y Container Threat Detection en GCP. 2. Opción de escaneo: programe escaneos periódicos completos (disco, memoria, arranque) y mantenga el escaneo en acceso del agente; en AWS puede complementarse con GuardDuty Malware Protection bajo demanda o escaneos de respaldos con AWS Backup. 3. Para almacenamiento de objetos, use GuardDuty Malware Protection for S3 y Defender for Storage para escanear cada carga. 4. Revise que todos los sistemas operativos en riesgo (Linux y Windows) estén cubiertos. Evidencia: configuración de la solución, cobertura por sistema y resultados recientes de escaneo o detecciones de comportamiento.", "descripcion_corta_en": "Anti-malware performs periodic and real-time scans, or continuous behavioral analysis", "descripcion_larga_en": "The anti-malware solution must meet at least one of two modes: perform periodic scans together with active or real-time scanning, or perform continuous behavioral analysis of systems or processes. It must be enabled on all operating system types identified as at risk, and logs and results must show it. The goal is that malware cannot complete execution.", "remediacion_en": "1. Continuous behavior option: enable GuardDuty Runtime Monitoring on EC2, EKS and ECS/Fargate; Defender for Endpoint with real-time protection and EDR in block mode on Azure; VM Threat Detection and Container Threat Detection on GCP. 2. Scan option: schedule periodic full scans (disk, memory, boot) and keep the agent's on-access scanning; on AWS this can be complemented with on-demand GuardDuty Malware Protection or AWS Backup restore-point scans. 3. For object storage, use GuardDuty Malware Protection for S3 and Defender for Storage to scan every upload. 4. Confirm all at-risk operating systems (Linux and Windows) are covered. Evidence: solution configuration, per-system coverage and recent scan results or behavioral detections.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 131, "pagina_pdf_es": 141 }, "kyber_cobertura": { "tipo": "deteccion_presencia", "automatizacion": "media", "checks_aws": [ "GuardDuty Runtime Monitoring (RUNTIME_MONITORING) habilitado con cobertura saludable en EC2/EKS/ECS (falla si hay recursos del CDE con cobertura no saludable)", "GuardDuty Malware Protection for EC2 habilitado para escaneos iniciados por GuardDuty y bajo demanda", "GuardDuty Malware Protection for S3 activo en buckets de carga del CDE" ], "checks_azure": [ "Defender for Servers Plan 2 o MDE con protección en tiempo real activa en VM del CDE (falla si realTimeProtection deshabilitado)", "Defender for Storage con escaneo de malware al cargar habilitado" ], "checks_gcp": [ "Container Threat Detection habilitado y clústeres GKE con versión compatible", "VM Threat Detection habilitado en SCC para los proyectos del CDE" ], "evidencia": "Kyber reporta la cobertura de detección continua o de escaneo por recurso; el cliente aporta resultados de escaneos recientes.", "evidencia_en": "Kyber reports continuous detection or scanning coverage per resource; the customer provides recent scan results.", "limitaciones": "No se valida la profundidad del escaneo (memoria, registros de arranque) ni la calidad de la detección de comportamiento.", "limitaciones_en": "Scan depth (memory, boot records) and behavioral detection quality are not validated.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.7" ], "soc2_tsc": [ "CC6.8", "CC7.2" ], "cis_controls_v8": [ "10.1", "10.7" ], "banxico_spei": [ "58a. I.A.b).2" ] } }, { "id": 70, "numero_regla": "5.3.2.1", "requisito": "5", "seccion": "5.3", "categoria": "Requisito 5: Proteger todos los sistemas y redes contra software malicioso", "categoria_en": "Requirement 5: Protect All Systems and Networks from Malicious Software", "seccion_titulo": "Mecanismos anti-malware activos, mantenidos y monitoreados", "seccion_titulo_en": "Anti-malware mechanisms are active, maintained, and monitored", "descripcion_corta": "Frecuencia de escaneos periódicos de malware definida por análisis de riesgo específico", "descripcion_larga": "Cuando el Requisito 5.3.2 se cumple mediante escaneos periódicos de malware, su frecuencia debe establecerse en un análisis de riesgo específico de la entidad realizado conforme a todos los elementos del Requisito 12.3.1. Los escaneos deben ejecutarse con la periodicidad definida. Solo aplica a quienes usan escaneos periódicos; fue mejor práctica hasta el 31 de marzo de 2025 y ahora es obligatorio.", "remediacion": "1. Si usa escaneos periódicos (no solo análisis continuo de comportamiento), elabore un TRA según 12.3.1 que determine la frecuencia por tipo de sistema y exposición. 2. Configure la programación en la herramienta (p. ej. escaneo completo programado en Defender for Endpoint mediante Intune/GPO, o escaneos programados de respaldos con AWS Backup y GuardDuty). 3. Monitoree que los escaneos se ejecuten y alerte si se omiten. 4. Revise el TRA cada 12 meses. Evidencia: TRA aprobado, configuración de la programación y bitácoras de escaneos en la frecuencia definida.", "descripcion_corta_en": "Frequency of periodic malware scans defined by a targeted risk analysis", "descripcion_larga_en": "Where Requirement 5.3.2 is met through periodic malware scans, their frequency must be set in the entity's targeted risk analysis performed according to all elements of Requirement 12.3.1. Scans must run at the defined frequency. It only applies to entities using periodic scans; it was a best practice until 31 March 2025 and is now mandatory.", "remediacion_en": "1. If periodic scans are used (not only continuous behavioral analysis), perform a TRA per 12.3.1 that sets frequency by system type and exposure. 2. Configure the schedule in the tool (e.g., scheduled full scan in Defender for Endpoint via Intune/GPO, or scheduled AWS Backup scans with GuardDuty). 3. Monitor that scans run and alert on missed scans. 4. Review the TRA every 12 months. Evidence: approved TRA, schedule configuration and scan logs at the defined frequency.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 132, "pagina_pdf_es": 143 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "TRA aprobado y bitácoras de escaneos cargados por el cliente; Kyber puede generar la plantilla de TRA.", "evidencia_en": "Approved TRA and scan logs uploaded by the customer; Kyber can generate the TRA template.", "limitaciones": "Kyber no evalúa la idoneidad de la frecuencia elegida.", "limitaciones_en": "Kyber does not assess the suitability of the chosen frequency.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.7", "5.7" ], "soc2_tsc": [ "CC3.2", "CC6.8" ], "cis_controls_v8": [ "10.1" ] } }, { "id": 71, "numero_regla": "5.3.3", "requisito": "5", "seccion": "5.3", "categoria": "Requisito 5: Proteger todos los sistemas y redes contra software malicioso", "categoria_en": "Requirement 5: Protect All Systems and Networks from Malicious Software", "seccion_titulo": "Mecanismos anti-malware activos, mantenidos y monitoreados", "seccion_titulo_en": "Anti-malware mechanisms are active, maintained, and monitored", "descripcion_corta": "Escaneo automático o análisis de comportamiento al conectar medios electrónicos extraíbles", "descripcion_larga": "Para los medios electrónicos extraíbles, la solución antimalware debe escanearlos automáticamente cuando se insertan, conectan o montan lógicamente, o bien realizar análisis continuo del comportamiento de sistemas o procesos en ese momento. El objetivo es evitar que se introduzca malware a través de medios externos como memorias USB. Fue mejor práctica hasta el 31 de marzo de 2025 y ahora es obligatorio.", "remediacion": "1. En estaciones de trabajo y servidores físicos con acceso al CDE, configure el EDR (p. ej. Defender for Endpoint mediante Intune o GPO) para escanear medios extraíbles al montarlos y aplique control de dispositivos. 2. Restrinja o bloquee el uso de USB en equipos administrativos cuando no sea necesario. 3. En la nube, documente que las VM no admiten medios extraíbles físicos y trate los volúmenes adjuntos como parte del escaneo de 5.3.2. 4. Conserve bitácoras de los escaneos de medios. Evidencia: políticas de control de dispositivos, configuración del EDR y registros de escaneo de medios extraíbles.", "descripcion_corta_en": "Automatic scan or behavioral analysis when removable electronic media is connected", "descripcion_larga_en": "For removable electronic media, the anti-malware solution must automatically scan the media when it is inserted, connected or logically mounted, or perform continuous behavioral analysis of systems or processes at that time. The goal is to prevent malware from being introduced via external media such as USB drives. This was a best practice until 31 March 2025 and is now mandatory.", "remediacion_en": "1. On workstations and physical servers with CDE access, configure the EDR (e.g., Defender for Endpoint via Intune or GPO) to scan removable media on mount and enforce device control. 2. Restrict or block USB use on administrative machines where unnecessary. 3. In the cloud, document that VMs do not support physical removable media and treat attached volumes as part of 5.3.2 scanning. 4. Keep media scan logs. Evidence: device control policies, EDR configuration and removable-media scan records.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 133, "pagina_pdf_es": 144 }, "kyber_cobertura": { "tipo": "fuera_alcance_agentless", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Configuración del EDR/control de dispositivos en endpoints y bitácoras de escaneo de medios, cargadas por el cliente.", "evidencia_en": "Endpoint EDR/device control configuration and media scan logs, uploaded by the customer.", "limitaciones": "Los medios extraíbles residen en endpoints físicos; el escaneo agentless de nube no los cubre.", "limitaciones_en": "Removable media lives on physical endpoints; agentless cloud scanning does not cover it.", "responsabilidad_compartida": "cliente", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "7.10", "8.7" ], "soc2_tsc": [ "CC6.7", "CC6.8" ], "cis_controls_v8": [ "10.3", "10.4" ], "banxico_spei": [ "58a. I.A.d).2" ] } }, { "id": 72, "numero_regla": "5.3.4", "requisito": "5", "seccion": "5.3", "categoria": "Requisito 5: Proteger todos los sistemas y redes contra software malicioso", "categoria_en": "Requirement 5: Protect All Systems and Networks from Malicious Software", "seccion_titulo": "Mecanismos anti-malware activos, mantenidos y monitoreados", "seccion_titulo_en": "Anti-malware mechanisms are active, maintained, and monitored", "descripcion_corta": "Bitácoras de auditoría del antimalware habilitadas y retenidas conforme a 10.5.1", "descripcion_larga": "Las bitácoras de auditoría de la solución antimalware deben estar habilitadas y conservarse según el Requisito 10.5.1, es decir, al menos 12 meses con los tres más recientes disponibles de inmediato. Esto permite verificar que actualizaciones y escaneos se ejecutan, que el malware se identifica y atiende, y reconstruir cómo ingresó y se movió en el entorno.", "remediacion": "1. AWS: exporte los hallazgos de GuardDuty a un bucket S3 cifrado con KMS (publishing destination) y envíe hallazgos a Security Hub; GuardDuty conserva hallazgos solo 90 días, por lo que la exportación es necesaria. Aplique regla de ciclo de vida que retenga al menos 365 días y Object Lock si es posible. 2. Azure: active la exportación continua de Defender for Cloud y las alertas de MDE hacia un área de trabajo de Log Analytics con retención total de al menos 365 días (90 días interactivos más archivo). 3. GCP: exporte hallazgos de SCC a BigQuery o a un sink de Cloud Logging con bucket de retención de 365 días o más. 4. Integre con el SIEM. Evidencia: configuración de exportación y retención, y consultas que muestren registros de hace 3 y 12 meses.", "descripcion_corta_en": "Anti-malware audit logs enabled and retained per Requirement 10.5.1", "descripcion_larga_en": "Audit logs of the anti-malware solution must be enabled and retained per Requirement 10.5.1, meaning at least 12 months with the most recent three months immediately available. This allows confirming that updates and scans run, that malware is identified and handled, and reconstructing how it entered and moved through the environment.", "remediacion_en": "1. AWS: export GuardDuty findings to a KMS-encrypted S3 bucket (publishing destination) and send findings to Security Hub; GuardDuty keeps findings only 90 days, so export is required. Apply a lifecycle rule retaining at least 365 days and Object Lock where possible. 2. Azure: enable Defender for Cloud continuous export and MDE alerts to a Log Analytics workspace with total retention of at least 365 days (90 interactive plus archive). 3. GCP: export SCC findings to BigQuery or a Cloud Logging sink with a bucket retention of 365 days or more. 4. Integrate with the SIEM. Evidence: export and retention configuration, and queries showing records from 3 and 12 months ago.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 134, "pagina_pdf_es": 145 }, "kyber_cobertura": { "tipo": "retencion_medible", "automatizacion": "alta", "checks_aws": [ "GuardDuty con publishing destination a S3 configurado en cada detector (falla si no existe)", "Bucket S3 de hallazgos con regla de ciclo de vida que no expire objetos antes de 365 días y cifrado SSE-KMS", "Security Hub habilitado e integrado con GuardDuty en las cuentas del CDE" ], "checks_azure": [ "Defender for Cloud: continuous export (automations) de alertas hacia Log Analytics habilitado", "Log Analytics workspace con retentionInDays + totalRetentionInDays ≥ 365 (falla si menor)" ], "checks_gcp": [ "Exportación continua de hallazgos de SCC a BigQuery o Pub/Sub configurada", "Bucket de Cloud Logging de destino con retentionDays ≥ 365 (falla si menor)" ], "evidencia": "Kyber mide la retención configurada contra 12 meses y reporta la existencia de exportación de hallazgos.", "evidencia_en": "Kyber measures configured retention against 12 months and reports whether findings export exists.", "limitaciones": "No verifica que las bitácoras sean completas ni que los 3 meses recientes estén disponibles de inmediato en el SIEM del cliente.", "limitaciones_en": "Does not verify log completeness or that the most recent 3 months are immediately available in the customer's SIEM.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.15", "8.7" ], "soc2_tsc": [ "CC7.2", "CC6.8" ], "cis_controls_v8": [ "8.2", "8.10", "10.1" ] } }, { "id": 73, "numero_regla": "5.3.5", "requisito": "5", "seccion": "5.3", "categoria": "Requisito 5: Proteger todos los sistemas y redes contra software malicioso", "categoria_en": "Requirement 5: Protect All Systems and Networks from Malicious Software", "seccion_titulo": "Mecanismos anti-malware activos, mantenidos y monitoreados", "seccion_titulo_en": "Anti-malware mechanisms are active, maintained, and monitored", "descripcion_corta": "Mecanismos antimalware no deshabilitables por usuarios sin autorización documentada", "descripcion_larga": "Los usuarios no deben poder desactivar ni modificar los mecanismos antimalware, salvo que exista una autorización específica de la administración, documentada caso por caso y con duración limitada. Solo se permite deshabilitarlos por una necesidad técnica legítima, y puede ser necesario aplicar medidas de seguridad adicionales durante el periodo sin protección.", "remediacion": "1. AWS: aplique SCP que nieguen guardduty:DeleteDetector, UpdateDetector, DisassociateFromAdministratorAccount, DeleteMalwareProtectionPlan y acciones equivalentes salvo para el rol de seguridad; administre GuardDuty desde una cuenta de administrador delegado. 2. Azure: active la protección contra manipulaciones (tamper protection) de Defender for Endpoint, use Azure Policy con efecto Deny/DeployIfNotExists para planes de Defender y limite con RBAC quién cambia los pricings. 3. GCP: restrinja roles securitycenter.admin y la modificación de servicios de SCC con IAM y políticas de organización. 4. Establezca un flujo de excepciones con ticket, aprobación de la dirección, fecha de expiración y medidas compensatorias (aislar de Internet, escaneo completo al reactivar). 5. Alerte sobre eventos de desactivación en CloudTrail/Activity Log/Cloud Audit Logs. Evidencia: políticas de denegación, estado de tamper protection, alertas configuradas y tickets de excepción aprobados.", "descripcion_corta_en": "Anti-malware mechanisms cannot be disabled by users without documented authorization", "descripcion_larga_en": "Users must not be able to disable or alter anti-malware mechanisms unless management has specifically authorized it, documented case by case and for a limited time. Disabling is only allowed for a legitimate technical need, and additional security measures may be needed while protection is inactive.", "remediacion_en": "1. AWS: apply SCPs denying guardduty:DeleteDetector, UpdateDetector, DisassociateFromAdministratorAccount, DeleteMalwareProtectionPlan and equivalent actions except for the security role; manage GuardDuty from a delegated administrator account. 2. Azure: enable Defender for Endpoint tamper protection, use Azure Policy with Deny/DeployIfNotExists for Defender plans and limit through RBAC who can change pricings. 3. GCP: restrict securitycenter.admin roles and changes to SCC services with IAM and organization policies. 4. Establish an exception workflow with ticket, management approval, expiry date and compensating measures (isolate from Internet, full scan on re-enable). 5. Alert on disable events in CloudTrail/Activity Log/Cloud Audit Logs. Evidence: deny policies, tamper protection status, configured alerts and approved exception tickets.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 135, "pagina_pdf_es": 146 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "SCP de AWS Organizations que niega guardduty:DeleteDetector/UpdateDetector/Disassociate* a roles distintos del de seguridad (falla si no existe)", "Cuentas miembro de GuardDuty administradas por cuenta de administrador delegado (falla si alguna cuenta es independiente)", "Alarma o regla de EventBridge sobre eventos de CloudTrail de desactivación de GuardDuty (falla si no existe)" ], "checks_azure": [ "Defender for Endpoint: tamper protection habilitado a nivel tenant/dispositivos del CDE", "Asignación de Azure Policy que exige planes de Defender for Cloud (DeployIfNotExists) en el grupo de administración del CDE", "Alerta de Activity Log sobre Microsoft.Security/pricings/write (falla si no existe)" ], "checks_gcp": [ "Principales con roles/securitycenter.admin u owner en proyectos del CDE fuera del grupo de seguridad (falla si existen)", "Métrica basada en logs/alerta para cambios de configuración de servicios de SCC en Cloud Audit Logs" ], "evidencia": "Kyber reporta políticas de denegación, estado de tamper protection y alertas; el cliente aporta los tickets de excepción aprobados.", "evidencia_en": "Kyber reports deny policies, tamper protection status and alerts; the customer provides approved exception tickets.", "limitaciones": "No puede validar que cada desactivación haya sido autorizada caso por caso ni las medidas compensatorias aplicadas.", "limitaciones_en": "Cannot validate that each disablement was authorized case by case or that compensating measures were applied.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.7", "8.2" ], "soc2_tsc": [ "CC6.8", "CC6.1" ], "cis_controls_v8": [ "10.1", "10.6" ] } }, { "id": 74, "numero_regla": "6.1.1", "requisito": "6", "seccion": "6.1", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Procesos y mecanismos de desarrollo seguro definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for secure development are defined and understood", "descripcion_corta": "Políticas y procedimientos operativos del Requisito 6 (sistemas y software seguros) gestionados", "descripcion_larga": "Las políticas de seguridad y los procedimientos operativos que respaldan el desarrollo y mantenimiento seguro de sistemas y software (Requisito 6) deben estar documentados, actualizados, aplicarse en la práctica y ser conocidos por todas las partes involucradas. Así, las actividades del requisito se ejecutan de manera repetible, consistente y conforme a la intención de la dirección.", "remediacion": "1. Documente políticas de ciclo de vida de desarrollo seguro, gestión de vulnerabilidades y parches, protección de aplicaciones web públicas, gestión de scripts de páginas de pago y control de cambios. 2. Defina procedimientos operativos: revisión de código, triaje de CVE detectadas (p. ej. por Kyber o Amazon Inspector), ventanas de parcheo con AWS Systems Manager Patch Manager, Azure Update Manager o GCP VM Manager, operación del WAF y separación de entornos. 3. Revise al menos cada 12 meses con control de versiones. 4. Difunda y recabe acuses de lectura. Evidencia: documentos vigentes, historial de versiones y registros de difusión.", "descripcion_corta_en": "Requirement 6 (secure systems and software) security policies and operational procedures are managed", "descripcion_larga_en": "Security policies and operational procedures supporting secure development and maintenance of systems and software (Requirement 6) must be documented, kept current, actually used, and known to all affected parties. This ensures the requirement's activities are performed repeatably, consistently and according to management's intent.", "remediacion_en": "1. Document policies for the secure development lifecycle, vulnerability and patch management, public-facing web application protection, payment page script management and change control. 2. Define operating procedures: code review, triage of detected CVEs (e.g., by Kyber or Amazon Inspector), patch windows with AWS Systems Manager Patch Manager, Azure Update Manager or GCP VM Manager, WAF operation and environment separation. 3. Review at least every 12 months under version control. 4. Disseminate and collect read acknowledgments. Evidence: current documents, version history and dissemination records.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 139, "pagina_pdf_es": 150 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Políticas y procedimientos del Requisito 6 con historial de versiones y acuses; Kyber puede generar plantillas mediante su generador de políticas.", "evidencia_en": "Requirement 6 policies and procedures with version history and acknowledgments; Kyber can produce templates through its policy generator.", "limitaciones": "El escaneo no puede verificar que las políticas estén en uso ni que el personal las conozca.", "limitaciones_en": "Scanning cannot verify that policies are in use or known to personnel.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.1", "5.37", "8.25" ], "soc2_tsc": [ "CC2.2", "CC5.3" ], "cis_controls_v8": [] } }, { "id": 75, "numero_regla": "6.1.2", "requisito": "6", "seccion": "6.1", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Procesos y mecanismos de desarrollo seguro definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for secure development are defined and understood", "descripcion_corta": "Roles y responsabilidades del Requisito 6 documentados, asignados y comprendidos", "descripcion_larga": "Las funciones y responsabilidades para ejecutar las actividades del Requisito 6 (desarrollo y mantenimiento seguro de sistemas y software) deben estar documentadas, asignadas y ser comprendidas por las personas responsables. De este modo la operación diaria queda repartida y el personal rinde cuentas por su funcionamiento continuo. Pueden documentarse en políticas o en documentos separados, como una matriz RACI.", "remediacion": "1. Elabore una matriz RACI para desarrollo seguro, revisión de código, gestión de vulnerabilidades y parches, administración del WAF, inventario de scripts de pago y control de cambios. 2. Asigne responsables por aplicación y por cuenta/suscripción/proyecto de nube. 3. Comunique la matriz y obtenga acuse de aceptación. 4. Revísela cada 12 meses o ante cambios organizacionales. Evidencia: matriz vigente, descripciones de puesto y acuses; entrevistas que confirmen la comprensión del rol.", "descripcion_corta_en": "Requirement 6 roles and responsibilities are documented, assigned and understood", "descripcion_larga_en": "Roles and responsibilities for performing Requirement 6 activities (secure development and maintenance of systems and software) must be documented, assigned and understood by those responsible. This allocates day-to-day operation and holds personnel accountable for its continuous functioning. They may be documented in policies or separate documents, such as a RACI matrix.", "remediacion_en": "1. Build a RACI matrix for secure development, code review, vulnerability and patch management, WAF administration, payment script inventory and change control. 2. Assign owners per application and per cloud account/subscription/project. 3. Communicate the matrix and collect acceptance acknowledgments. 4. Review it every 12 months or upon organizational changes. Evidence: current matrix, job descriptions and acknowledgments; interviews confirming role understanding.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 140, "pagina_pdf_es": 151 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Matriz RACI y acuses de aceptación cargados por el cliente; Kyber puede generar la plantilla.", "evidencia_en": "RACI matrix and acceptance acknowledgments uploaded by the customer; Kyber can generate the template.", "limitaciones": "No es verificable mediante escaneo de nube; requiere entrevistas.", "limitaciones_en": "Not verifiable through cloud scanning; requires interviews.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.2", "5.3" ], "soc2_tsc": [ "CC1.3", "CC5.3" ], "cis_controls_v8": [] } }, { "id": 76, "numero_regla": "6.2.1", "requisito": "6", "seccion": "6.2", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Software a medida y personalizado desarrollado de forma segura", "seccion_titulo_en": "Bespoke and custom software is developed securely", "descripcion_corta": "Software a medida y personalizado desarrollado de forma segura", "descripcion_larga": "El software a medida y personalizado debe desarrollarse de forma segura: con base en estándares de la industria o mejores prácticas de desarrollo seguro, de acuerdo con PCI DSS (por ejemplo, autenticación segura y registro de eventos) y considerando aspectos de seguridad de la información en cada etapa del ciclo de vida. Aplica a todo el software desarrollado por o para la entidad para su propio uso, pero no al software de terceros.", "remediacion": "1. Adopte un marco de desarrollo seguro reconocido (PCI Secure Software Framework, OWASP SAMM, NIST SSDF SP 800-218, BSIMM). 2. Integre seguridad en cada fase: requisitos de seguridad y PCI DSS en el diseño, modelado de amenazas, revisión de código, pruebas SAST/DAST/SCA en el pipeline (p. ej. AWS CodePipeline, Azure DevOps, Cloud Build) y verificación previa al despliegue. 3. Incluya requisitos de PCI DSS por diseño: MFA, bitácoras de auditoría (Req. 10), cifrado de PAN y no almacenamiento de SAD. 4. Documente el procedimiento y conserve artefactos por versión. Evidencia: procedimiento de SDLC aprobado, modelos de amenazas, reportes de pruebas de seguridad y registros de aprobación de liberaciones.", "descripcion_corta_en": "Bespoke and custom software is developed securely", "descripcion_larga_en": "Bespoke and custom software must be developed securely: based on industry standards or best practices for secure development, in accordance with PCI DSS (for example, secure authentication and logging), and considering information security issues in every stage of the software lifecycle. It applies to all software developed by or for the entity for its own use, but not to third-party software.", "remediacion_en": "1. Adopt a recognized secure development framework (PCI Secure Software Framework, OWASP SAMM, NIST SSDF SP 800-218, BSIMM). 2. Embed security in every phase: security and PCI DSS requirements in design, threat modeling, code review, SAST/DAST/SCA in the pipeline (e.g., AWS CodePipeline, Azure DevOps, Cloud Build) and pre-deployment verification. 3. Build PCI DSS requirements in by design: MFA, audit logging (Req. 10), PAN encryption and no SAD storage. 4. Document the procedure and keep per-release artifacts. Evidence: approved SDLC procedure, threat models, security testing reports and release approval records.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 141, "pagina_pdf_es": 152 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Procedimiento de SDLC seguro y artefactos de seguridad por liberación cargados por el cliente; Kyber puede generar la plantilla de política.", "evidencia_en": "Secure SDLC procedure and per-release security artifacts uploaded by the customer; Kyber can generate the policy template.", "limitaciones": "El escaneo de infraestructura no evalúa el proceso de desarrollo ni el código fuente.", "limitaciones_en": "Infrastructure scanning does not assess the development process or source code.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.25", "8.26", "8.27" ], "soc2_tsc": [ "CC8.1", "CC3.2" ], "cis_controls_v8": [ "16.1", "16.10" ], "banxico_spei": [ "58a. I.A.c).1", "58a. I.A.c).2", "58a. I.C.e)" ] }, "mapeo_ucf": [ { "clave": "UCF-SDL-001", "relacion": "equivalent", "cobertura_pct": 90 } ] }, { "id": 77, "numero_regla": "6.2.2", "requisito": "6", "seccion": "6.2", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Software a medida y personalizado desarrollado de forma segura", "seccion_titulo_en": "Bespoke and custom software is developed securely", "descripcion_corta": "Capacitación anual en seguridad de software para el personal de desarrollo", "descripcion_larga": "El personal de desarrollo que trabaja en software a medida y personalizado debe recibir capacitación al menos una vez cada 12 meses. Debe abarcar la seguridad de software pertinente a su función y lenguajes de desarrollo, el diseño seguro y las técnicas de codificación segura y, cuando se utilicen herramientas de pruebas de seguridad, cómo emplearlas para detectar vulnerabilidades.", "remediacion": "1. Defina un programa anual de capacitación por rol y lenguaje (p. ej. OWASP Top 10, OWASP API Security Top 10, CWE Top 25, ataques de enumeración en pagos). 2. Incluya diseño seguro, codificación segura y uso de las herramientas SAST/DAST/SCA adoptadas. 3. Actualice el contenido cuando cambien las prácticas o surjan nuevas amenazas. 4. Registre asistencia y evaluaciones en un LMS y dé seguimiento a pendientes. Evidencia: plan de capacitación, materiales y registros de finalización de los últimos 12 meses por desarrollador.", "descripcion_corta_en": "Annual software security training for development personnel", "descripcion_larga_en": "Development personnel working on bespoke and custom software must be trained at least once every 12 months. Training must cover software security relevant to their job function and development languages, secure software design and secure coding techniques, and, where security testing tools are used, how to use them to detect vulnerabilities.", "remediacion_en": "1. Define an annual training program by role and language (e.g., OWASP Top 10, OWASP API Security Top 10, CWE Top 25, payment enumeration attacks). 2. Include secure design, secure coding and use of the adopted SAST/DAST/SCA tools. 3. Update content as practices change or new threats appear. 4. Record attendance and assessments in an LMS and follow up on gaps. Evidence: training plan, materials and completion records for the last 12 months per developer.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 142, "pagina_pdf_es": 153 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Plan de capacitación y registros de finalización por desarrollador cargados por el cliente.", "evidencia_en": "Training plan and per-developer completion records uploaded by the customer.", "limitaciones": "Sin componente técnico verificable por escaneo de nube.", "limitaciones_en": "No technical component verifiable through cloud scanning.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "6.3", "8.28" ], "soc2_tsc": [ "CC1.4", "CC2.2" ], "cis_controls_v8": [ "16.9", "14.1" ], "banxico_spei": [ "58a. I.A.c).2" ] } }, { "id": 78, "numero_regla": "6.2.3", "requisito": "6", "seccion": "6.2", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Software a medida y personalizado desarrollado de forma segura", "seccion_titulo_en": "Bespoke and custom software is developed securely", "descripcion_corta": "Revisión de código del software a medida y personalizado antes de su liberación", "descripcion_larga": "Antes de liberar software a medida y personalizado a producción o a clientes, debe revisarse para identificar y corregir posibles vulnerabilidades de codificación. Las revisiones deben confirmar que se siguen las pautas de codificación segura, buscar vulnerabilidades existentes y emergentes, y asegurar que se implementen las correcciones antes de la liberación. Aplica a todo este software, interno o público, y puede hacerse de forma manual, automatizada o combinada; las aplicaciones web públicas tienen además los controles de 6.4.", "remediacion": "1. Exija revisión de código en cada cambio mediante pull requests con reglas de protección de rama (GitHub, GitLab, Azure Repos, AWS CodeCommit) y aprobaciones obligatorias. 2. Integre análisis automatizado en el pipeline: SAST (p. ej. CodeQL, Semgrep, Amazon CodeGuru Security), SCA para dependencias y detección de secretos, con umbrales que bloqueen la liberación ante hallazgos críticos o altos. 3. Revise también puertas traseras, uso seguro de librerías, registro de datos sensibles y lógica de negocio. 4. Corrija y vuelva a analizar antes de liberar. Evidencia: registros de pull requests aprobados, reportes de análisis por versión y tickets de corrección cerrados antes del despliegue.", "descripcion_corta_en": "Code review of bespoke and custom software before release", "descripcion_larga_en": "Before bespoke and custom software is released to production or customers, it must be reviewed to identify and correct potential coding vulnerabilities. Reviews must confirm adherence to secure coding guidelines, look for existing and emerging vulnerabilities, and ensure corrections are implemented before release. It applies to all such software, internal or public-facing, and may be manual, automated or both; public-facing web applications are also subject to 6.4 controls.", "remediacion_en": "1. Require code review for every change through pull requests with branch protection rules (GitHub, GitLab, Azure Repos, AWS CodeCommit) and mandatory approvals. 2. Embed automated analysis in the pipeline: SAST (e.g., CodeQL, Semgrep, Amazon CodeGuru Security), SCA for dependencies and secret detection, with thresholds that block release on critical or high findings. 3. Also review for backdoors, secure library use, sensitive data logging and business logic. 4. Fix and re-scan before release. Evidence: approved pull request records, per-release analysis reports and remediation tickets closed before deployment.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 143, "pagina_pdf_es": 154 }, "kyber_cobertura": { "tipo": "servicio", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Registros de pull requests aprobados y reportes SAST/SCA por liberación aportados por el cliente o por un servicio de revisión de código.", "evidencia_en": "Approved pull request records and per-release SAST/SCA reports provided by the customer or a code review service.", "limitaciones": "El escaneo de infraestructura no revisa código fuente ni el proceso de aprobación de cambios.", "limitaciones_en": "Infrastructure scanning does not review source code or the change approval process.", "responsabilidad_compartida": "cliente", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.28", "8.29", "8.25" ], "soc2_tsc": [ "CC8.1", "CC7.1" ], "cis_controls_v8": [ "16.12", "16.2" ], "banxico_spei": [ "58a. I.A.c).4", "58a. I.C.g)" ] } }, { "id": 79, "numero_regla": "6.2.3.1", "requisito": "6", "seccion": "6.2", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Software a medida y personalizado desarrollado de forma segura", "seccion_titulo_en": "Bespoke and custom software is developed securely", "descripcion_corta": "Revisiones manuales de código por personas distintas al autor y aprobadas por la dirección", "descripcion_larga": "Cuando se realicen revisiones manuales de código antes de liberar software a medida y personalizado, los cambios deben ser revisados por personas distintas al autor original que conozcan técnicas de revisión de código y prácticas de codificación segura, y deben ser revisados y aprobados por la dirección antes de la liberación. Los revisores pueden ser personal interno o externo capacitado; cumple el criterio de dirección una persona con responsabilidad formal sobre el control de liberaciones que no sea ni el autor ni el revisor.", "remediacion": "1. Configure las reglas de protección de rama para impedir que el autor apruebe su propio cambio y exija al menos un revisor calificado (p. ej. CODEOWNERS de seguridad). 2. Defina un aprobador de liberaciones con responsabilidad formal, distinto del autor y del revisor, mediante entornos protegidos con aprobación manual (GitHub Environments, Azure DevOps approvals, AWS CodePipeline manual approval, Cloud Deploy approvals). 3. Use listas de verificación de revisión y mantenga a los revisores capacitados. 4. Conserve el rastro de quién revisó y quién aprobó cada cambio. Evidencia: configuración de protección de ramas y aprobaciones, y muestra de cambios con revisor y aprobador identificados.", "descripcion_corta_en": "Manual code reviews by someone other than the author and approved by management", "descripcion_larga_en": "Where manual code reviews are performed before releasing bespoke and custom software, changes must be reviewed by individuals other than the original author who are knowledgeable in code review techniques and secure coding practices, and must be reviewed and approved by management before release. Reviewers may be knowledgeable internal or third-party personnel; a person formally accountable for release control who is neither the author nor the reviewer qualifies as management.", "remediacion_en": "1. Configure branch protection so authors cannot approve their own changes and require at least one qualified reviewer (e.g., security CODEOWNERS). 2. Define a release approver with formal accountability, separate from author and reviewer, using protected environments with manual approval (GitHub Environments, Azure DevOps approvals, AWS CodePipeline manual approval, Cloud Deploy approvals). 3. Use review checklists and keep reviewers trained. 4. Retain the trail of who reviewed and who approved each change. Evidence: branch protection and approval configuration, and a sample of changes with identified reviewer and approver.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 144, "pagina_pdf_es": 155 }, "kyber_cobertura": { "tipo": "servicio", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Configuración de protección de ramas y muestra de cambios con revisor y aprobador distintos, aportada por el cliente o un servicio de revisión.", "evidencia_en": "Branch protection configuration and a sample of changes with distinct reviewer and approver, provided by the customer or a review service.", "limitaciones": "No verificable con escaneo agentless de la infraestructura de nube.", "limitaciones_en": "Not verifiable with agentless cloud infrastructure scanning.", "responsabilidad_compartida": "cliente", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.28", "8.32", "5.3" ], "soc2_tsc": [ "CC8.1" ], "cis_controls_v8": [ "16.12" ] } }, { "id": 80, "numero_regla": "6.2.4", "requisito": "6", "seccion": "6.2", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Software a medida y personalizado desarrollado de forma segura", "seccion_titulo_en": "Bespoke and custom software is developed securely", "descripcion_corta": "Técnicas de ingeniería de software para prevenir o mitigar ataques comunes al software", "descripcion_larga": "El personal de desarrollo debe definir y aplicar técnicas de ingeniería de software u otros métodos para prevenir o mitigar ataques comunes y sus vulnerabilidades en el software a medida y personalizado. Como mínimo deben cubrirse: ataques de inyección (SQL, LDAP, XPath, comandos, parámetros, objetos, fallas); ataques a datos y estructuras de datos (búferes, apuntadores, entradas o datos compartidos); ataques al uso de criptografía débil o inapropiada (algoritmos, suites de cifrado, modos); ataques a la lógica de negocio mediante manipulación de API, protocolos, canales o funcionalidad del cliente, incluidos XSS y CSRF; ataques a mecanismos de control de acceso (identificación, autenticación, autorización); y ataques vía cualquier vulnerabilidad de alto riesgo identificada según 6.3.1. No aplica a software de terceros.", "remediacion": "1. Defina estándares de codificación segura por lenguaje alineados con OWASP ASVS y OWASP Cheat Sheets: consultas parametrizadas, validación y codificación de salidas, protección CSRF, gestión segura de sesiones, criptografía aprobada (TLS 1.2+, AES-GCM) y controles anti-enumeración (rate limiting, CAPTCHA en flujos de pago). 2. Automatice la verificación en el pipeline con SAST, SCA y DAST, y bloquee la liberación ante hallazgos de estas categorías. 3. Use librerías y frameworks con protecciones integradas y gestión centralizada de secretos (AWS Secrets Manager, Azure Key Vault, Secret Manager). 4. Incluya pruebas de autorización (IDOR) y de abuso de API. Evidencia: estándares documentados, configuración de las herramientas en el pipeline y reportes que demuestren la cobertura de cada categoría.", "descripcion_corta_en": "Software engineering techniques to prevent or mitigate common software attacks", "descripcion_larga_en": "Development personnel must define and use software engineering techniques or other methods to prevent or mitigate common software attacks and related vulnerabilities in bespoke and custom software. At a minimum they must cover: injection attacks (SQL, LDAP, XPath, command, parameter, object, fault); attacks on data and data structures (buffers, pointers, input or shared data); attacks on weak or inappropriate cryptography use (algorithms, cipher suites, modes); business logic attacks through manipulation of APIs, protocols, channels or client-side functionality, including XSS and CSRF; attacks on access control mechanisms (identification, authentication, authorization); and attacks via any high-risk vulnerability identified under 6.3.1. It does not apply to third-party software.", "remediacion_en": "1. Define per-language secure coding standards aligned with OWASP ASVS and OWASP Cheat Sheets: parameterized queries, input validation and output encoding, CSRF protection, secure session handling, approved cryptography (TLS 1.2+, AES-GCM) and anti-enumeration controls (rate limiting, CAPTCHA on payment flows). 2. Automate verification in the pipeline with SAST, SCA and DAST, blocking release on findings in these categories. 3. Use libraries and frameworks with built-in protections and centralized secret management (AWS Secrets Manager, Azure Key Vault, Secret Manager). 4. Include authorization (IDOR) and API abuse testing. Evidence: documented standards, pipeline tool configuration and reports showing coverage of each category.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 145, "pagina_pdf_es": 156 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Estándares de codificación segura y reportes de herramientas de pruebas por categoría de ataque aportados por el cliente.", "evidencia_en": "Secure coding standards and testing tool reports per attack category provided by the customer.", "limitaciones": "El escaneo de nube no analiza el código de la aplicación; la protección en tiempo de ejecución se cubre parcialmente en 6.4.2.", "limitaciones_en": "Cloud scanning does not analyze application code; runtime protection is partially covered under 6.4.2.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.28", "8.26", "8.29" ], "soc2_tsc": [ "CC8.1", "CC7.1" ], "cis_controls_v8": [ "16.10", "16.12", "16.14" ], "banxico_spei": [ "58a. I.A.c).4" ] } }, { "id": 81, "numero_regla": "6.3.1", "requisito": "6", "seccion": "6.3", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Vulnerabilidades de seguridad identificadas y atendidas", "seccion_titulo_en": "Security vulnerabilities are identified and addressed", "descripcion_corta": "Identificación de vulnerabilidades de seguridad y asignación de clasificación de riesgo", "descripcion_larga": "Las vulnerabilidades de seguridad deben identificarse y gestionarse así: las nuevas se detectan usando fuentes reconocidas por la industria, incluidas alertas de equipos de respuesta a emergencias informáticas (CERT) nacionales e internacionales; cada una recibe una clasificación de riesgo basada en mejores prácticas y en su impacto potencial; la clasificación identifica como mínimo todas las de riesgo alto o crítico para el entorno; y se cubren tanto el software a medida y personalizado como el de terceros (p. ej. sistemas operativos y bases de datos). Este proceso de monitoreo activo es adicional a los escaneos de vulnerabilidades de 11.3.1 y 11.3.2 y no se satisface con ellos.", "remediacion": "1. Suscríbase a fuentes de vulnerabilidades (NVD, CISA KEV y alertas de CERT nacionales, boletines de AWS, Microsoft y Google, avisos de los fabricantes de librerías). 2. Active la detección continua de CVE: Kyber a partir de snapshots de discos (paquetes del SO y librerías), Amazon Inspector para EC2/ECR/Lambda, Microsoft Defender Vulnerability Management en Defender for Servers y Artifact Analysis/VM Manager en GCP. 3. Defina una metodología de clasificación (CVSS v3.1/v4 ajustado por exposición a Internet, explotación activa en KEV, EPSS y criticidad del activo) que identifique al menos altos y críticos. 4. Reevalúe periódicamente y considere combinaciones de vulnerabilidades. 5. Incluya dependencias del software propio mediante SCA. Evidencia: procedimiento, lista de fuentes, reportes de CVE con su clasificación y registros de triaje.", "descripcion_corta_en": "Security vulnerabilities are identified and assigned a risk ranking", "descripcion_larga_en": "Security vulnerabilities must be identified and managed as follows: new ones are identified using industry-recognized sources, including alerts from national and international computer emergency response teams (CERTs); each is assigned a risk ranking based on industry best practices and potential impact; rankings identify at a minimum all vulnerabilities considered high-risk or critical to the environment; and bespoke and custom as well as third-party software (e.g., operating systems and databases) are covered. This active monitoring process is in addition to, and not satisfied by, the vulnerability scans in 11.3.1 and 11.3.2.", "remediacion_en": "1. Subscribe to vulnerability sources (NVD, CISA KEV and national CERT alerts, AWS, Microsoft and Google bulletins, library vendor advisories). 2. Enable continuous CVE detection: Kyber from disk snapshots (OS packages and libraries), Amazon Inspector for EC2/ECR/Lambda, Microsoft Defender Vulnerability Management in Defender for Servers, and Artifact Analysis/VM Manager in GCP. 3. Define a ranking methodology (CVSS v3.1/v4 adjusted for Internet exposure, active exploitation in KEV, EPSS and asset criticality) that at least identifies high and critical. 4. Re-evaluate periodically and consider vulnerability chaining. 5. Cover in-house software dependencies through SCA. Evidence: procedure, source list, CVE reports with rankings and triage records.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 147, "pagina_pdf_es": 158 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Kyber: CVE en paquetes del SO y librerías detectadas a partir de snapshots de EBS, con clasificación CVSS/KEV (falla si hay críticas o altas sin triage)", "Amazon Inspector habilitado para escaneo de EC2 [Inspector.1], ECR [Inspector.2] y Lambda [Inspector.3]", "Repositorios ECR con escaneo de imágenes al publicar o escaneo mejorado habilitado" ], "checks_azure": [ "Kyber: CVE en paquetes del SO y librerías detectadas a partir de snapshots de discos administrados, con clasificación de riesgo", "Defender for Servers con evaluación de vulnerabilidades (MDVM) habilitada en las VM del CDE", "Defender for Containers / evaluación de vulnerabilidades de imágenes en Azure Container Registry habilitada" ], "checks_gcp": [ "Kyber: CVE en paquetes del SO y librerías detectadas a partir de snapshots de Persistent Disk, con clasificación de riesgo", "VM Manager (OS Config) con reportes de vulnerabilidades habilitado en proyectos del CDE", "Artifact Analysis (Container Scanning API) habilitado para Artifact Registry" ], "evidencia": "Kyber genera el reporte de CVE con clasificación de riesgo por recurso; el cliente aporta el procedimiento y la evidencia de monitoreo de fuentes como CERT.", "evidencia_en": "Kyber produces the CVE report with risk ranking per resource; the customer provides the procedure and evidence of monitoring sources such as CERTs.", "limitaciones": "No cubre vulnerabilidades del código propio (lógica de negocio) ni demuestra el monitoreo activo de fuentes de la industria por parte del cliente.", "limitaciones_en": "Does not cover vulnerabilities in in-house code (business logic) or demonstrate the customer's active monitoring of industry sources.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.8", "5.7" ], "soc2_tsc": [ "CC7.1", "CC3.2" ], "cis_controls_v8": [ "7.1", "7.2", "16.6" ], "banxico_spei": [ "58a. I.A.b).3", "58a. I.B.b)" ] }, "mapeo_ucf": [ { "clave": "UCF-VUL-001", "relacion": "equivalent", "cobertura_pct": 100 } ] }, { "id": 82, "numero_regla": "6.3.2", "requisito": "6", "seccion": "6.3", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Vulnerabilidades de seguridad identificadas y atendidas", "seccion_titulo_en": "Security vulnerabilities are identified and addressed", "descripcion_corta": "Inventario del software a medida y personalizado y de sus componentes de terceros", "descripcion_larga": "Debe mantenerse un inventario del software a medida y personalizado, así como de los componentes de software de terceros incorporados en él (librerías, API, etc.), para facilitar la gestión de vulnerabilidades y parches. El inventario debe usarse para identificar y atender vulnerabilidades. Fue mejor práctica hasta el 31 de marzo de 2025 y desde entonces es obligatorio.", "remediacion": "1. Genere un SBOM (CycloneDX o SPDX) por aplicación en el pipeline de construcción y almacénelo junto con cada versión. 2. Use el inventario de software que Kyber obtiene de los snapshots (paquetes del SO, librerías de lenguajes y versiones) y complételo con Amazon Inspector SBOM export, Defender for Cloud o Artifact Analysis para imágenes de contenedor. 3. Relacione cada componente con su aplicación y dueño, e incluya plataformas de ejecución y servicios requeridos. 4. Cruce el inventario contra fuentes de CVE para alimentar 6.3.1 y 6.3.3. Evidencia: inventario/SBOM vigente por aplicación, fecha de actualización y muestra de vulnerabilidades atendidas a partir de él.", "descripcion_corta_en": "Inventory of bespoke and custom software and its third-party components", "descripcion_larga_en": "An inventory of bespoke and custom software, and of third-party software components incorporated into it (libraries, APIs, etc.), must be maintained to facilitate vulnerability and patch management. The inventory must be used to identify and address vulnerabilities. This was a best practice until 31 March 2025 and is now mandatory.", "remediacion_en": "1. Generate an SBOM (CycloneDX or SPDX) per application in the build pipeline and store it with each release. 2. Use the software inventory Kyber derives from snapshots (OS packages, language libraries and versions) and complement it with Amazon Inspector SBOM export, Defender for Cloud or Artifact Analysis for container images. 3. Map each component to its application and owner, including execution platforms and required services. 4. Match the inventory against CVE sources to feed 6.3.1 and 6.3.3. Evidence: current inventory/SBOM per application, update date and a sample of vulnerabilities addressed from it.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 151, "pagina_pdf_es": 162 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Kyber: inventario de paquetes del SO y librerías (npm, pip, Maven, Composer, NuGet, Go) por instancia EC2 a partir de snapshots", "Amazon Inspector con exportación de SBOM habilitada para EC2/ECR/Lambda", "Funciones Lambda y imágenes ECR del CDE sin etiqueta de aplicación/dueño (falla si existen)" ], "checks_azure": [ "Kyber: inventario de paquetes del SO y librerías por VM a partir de snapshots de discos administrados", "Inventario de software de Defender for Cloud / Azure Resource Graph (softwareinventory) disponible para las VM del CDE" ], "checks_gcp": [ "Kyber: inventario de paquetes del SO y librerías por VM a partir de snapshots de Persistent Disk", "VM Manager OS inventory habilitado (metadata enable-osconfig = TRUE) en las VM del CDE" ], "evidencia": "Kyber genera el inventario de software y componentes de terceros desplegados (SBOM a partir de snapshots), con su relación de CVE.", "evidencia_en": "Kyber generates the inventory of deployed software and third-party components (SBOM from snapshots), linked to CVEs.", "limitaciones": "Solo ve componentes desplegados en cómputo escaneado; no identifica qué software es a medida ni componentes que no estén en discos o imágenes analizados (p. ej. dependencias del lado del navegador).", "limitaciones_en": "Only sees components deployed on scanned compute; it does not identify which software is bespoke or components not on analyzed disks or images (e.g., browser-side dependencies).", "responsabilidad_compartida": "cliente", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.9", "8.8", "8.19" ], "soc2_tsc": [ "CC7.1", "CC6.8" ], "cis_controls_v8": [ "2.1", "16.4", "16.5" ], "banxico_spei": [ "58a. I.A.c).3" ] } }, { "id": 83, "numero_regla": "6.3.3", "requisito": "6", "seccion": "6.3", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Vulnerabilidades de seguridad identificadas y atendidas", "seccion_titulo_en": "Security vulnerabilities are identified and addressed", "descripcion_corta": "Parches de seguridad instalados: críticos en un mes y demás según riesgo", "descripcion_larga": "Todos los componentes del sistema deben protegerse contra vulnerabilidades conocidas instalando los parches o actualizaciones de seguridad aplicables. Los correspondientes a vulnerabilidades críticas, identificadas mediante el proceso de clasificación de 6.3.1, deben instalarse dentro del mes posterior a su publicación; los demás, en un plazo adecuado determinado por la evaluación de la entidad sobre la criticidad del riesgo. Se recomienda documentar ese plazo en un análisis de riesgo específico; como referencia, 60 días para altos y 90 para el resto.", "remediacion": "1. Gestione parches de forma automatizada: AWS Systems Manager Patch Manager con patch baselines y ventanas de mantenimiento, Azure Update Manager con evaluación periódica y configuraciones de mantenimiento programadas, y GCP VM Manager OS patch deployments. 2. Defina SLA: críticos ≤ 30 días desde la publicación del parche; altos y demás según TRA (p. ej. 60/90 días). 3. Mantenga servicios administrados actualizados: actualización automática de versiones menores en RDS/Azure SQL/Cloud SQL, versiones soportadas de EKS/AKS/GKE con canales de actualización, runtimes de Lambda/Functions vigentes, e imágenes base reconstruidas. 4. Use los hallazgos de CVE de Kyber e Inspector para medir la antigüedad de cada vulnerabilidad con parche disponible y escalar las vencidas. Evidencia: reportes de cumplimiento de parches, SLA documentados y reporte de Kyber de CVE críticas con parche disponible y fecha.", "descripcion_corta_en": "Security patches installed: critical within one month, others based on risk", "descripcion_larga_en": "All system components must be protected from known vulnerabilities by installing applicable security patches or updates. Those for critical vulnerabilities, identified through the 6.3.1 ranking process, must be installed within one month of release; all others within an appropriate time frame based on the entity's assessment of risk criticality. Documenting that time frame in a targeted risk analysis is recommended; as an example, 60 days for high and 90 days for the rest.", "remediacion_en": "1. Automate patching: AWS Systems Manager Patch Manager with patch baselines and maintenance windows, Azure Update Manager with periodic assessment and scheduled maintenance configurations, and GCP VM Manager OS patch deployments. 2. Define SLAs: critical ≤ 30 days from patch release; high and others per TRA (e.g., 60/90 days). 3. Keep managed services current: automatic minor version upgrades on RDS/Azure SQL/Cloud SQL, supported EKS/AKS/GKE versions with release channels, current Lambda/Functions runtimes, and rebuilt base images. 4. Use Kyber and Inspector CVE findings to measure the age of each vulnerability with an available fix and escalate overdue ones. Evidence: patch compliance reports, documented SLAs and Kyber report of critical CVEs with available fix and dates.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 152, "pagina_pdf_es": 163 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Kyber: CVE críticas con parche disponible publicado hace más de 30 días en paquetes del SO o librerías del snapshot (falla si existen)", "Instancias EC2 administradas por Systems Manager [SSM.1] y con estado de cumplimiento de parches COMPLIANT [SSM.2]", "RDS con actualización automática de versiones menores habilitada [RDS.13]", "Clústeres EKS en versión de Kubernetes soportada [EKS.2]", "Funciones Lambda con runtime soportado [Lambda.2]" ], "checks_azure": [ "Kyber: CVE críticas con parche disponible publicado hace más de 30 días en VM del CDE (falla si existen)", "Azure Update Manager: assessmentMode = AutomaticByPlatform y máquinas sin actualizaciones de seguridad críticas pendientes", "AKS con canal de actualización automática configurado y versión de Kubernetes soportada", "App Service / Functions con versión de runtime soportada" ], "checks_gcp": [ "Kyber: CVE críticas con parche disponible publicado hace más de 30 días en VM del CDE (falla si existen)", "VM Manager con OS patch deployments programados en los proyectos del CDE", "GKE inscrito en canal de versiones con auto-upgrade de nodos habilitado", "Cloud SQL con ventana de mantenimiento configurada" ], "evidencia": "Kyber genera el reporte de antigüedad de CVE con parche disponible contra el SLA de 30 días para críticas; el cliente aporta el TRA de plazos para las demás.", "evidencia_en": "Kyber produces the report of CVE age with available fix against the 30-day SLA for critical; the customer provides the TRA for other time frames.", "limitaciones": "La fecha de publicación del parche se infiere de fuentes de avisos; no cubre dispositivos de red físicos ni endpoints, y el parcheo de la capa subyacente de servicios administrados corresponde al proveedor.", "limitaciones_en": "Patch release dates are inferred from advisory sources; physical network devices and endpoints are not covered, and patching the underlying layer of managed services is the provider's duty.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.8", "8.19" ], "soc2_tsc": [ "CC7.1", "CC8.1" ], "cis_controls_v8": [ "7.3", "7.4", "7.7" ], "banxico_spei": [ "58a. I.A.b).3", "58a. I.A.g).4" ] }, "mapeo_ucf": [ { "clave": "UCF-VUL-002", "relacion": "equivalent", "cobertura_pct": 100 } ] }, { "id": 84, "numero_regla": "6.4.1", "requisito": "6", "seccion": "6.4", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Aplicaciones web públicas protegidas contra ataques", "seccion_titulo_en": "Public-facing web applications are protected against attacks", "descripcion_corta": "Aplicaciones web públicas protegidas por evaluación anual de vulnerabilidades o solución automatizada", "descripcion_larga": "Para las aplicaciones web de cara al público, las nuevas amenazas y vulnerabilidades deben atenderse de forma continua mediante una de dos opciones. La primera es revisarlas con herramientas o métodos manuales o automatizados de evaluación de seguridad de aplicaciones al menos una vez cada 12 meses y tras cambios significativos, por una entidad especializada en seguridad de aplicaciones, cubriendo como mínimo los ataques de 6.2.4, clasificando las vulnerabilidades según 6.3.1, corrigiéndolas todas y reevaluando tras la corrección. La segunda es instalar una solución técnica automatizada frente a las aplicaciones que detecte y prevenga ataques web continuamente, esté activa y actualizada, genere bitácoras de auditoría y bloquee los ataques o genere alertas investigadas de inmediato. Esta evaluación no equivale a los escaneos de 11.3.1 y 11.3.2, y el requisito fue reemplazado por 6.4.2 a partir del 31 de marzo de 2025.", "remediacion": "1. Inventaríe las aplicaciones web y API públicas (CloudFront, ALB, API Gateway, Application Gateway, Front Door, balanceadores HTTP(S) de GCP). 2. Coloque un WAF delante de cada una: AWS WAF con grupos de reglas administradas (Core rule set, Known bad inputs, SQL database), Azure WAF en modo Prevención con el conjunto DRS, o Cloud Armor con reglas WAF preconfiguradas. 3. Habilite bitácoras del WAF y alertas que se investiguen de inmediato, y mantenga las reglas administradas actualizadas. 4. Si opta por evaluaciones, contrate pruebas de seguridad de aplicaciones anuales y tras cambios significativos, corrija todos los hallazgos y conserve el retest. Evidencia: configuración del WAF y bitácoras, o reportes de evaluación con retest. Migre a 6.4.2 (WAF obligatorio).", "descripcion_corta_en": "Public-facing web apps protected by annual vulnerability assessment or an automated solution", "descripcion_larga_en": "For public-facing web applications, new threats and vulnerabilities must be addressed on an ongoing basis through one of two options. The first is reviewing them with manual or automated application security assessment tools or methods at least every 12 months and after significant changes, by an entity specializing in application security, covering at least the 6.2.4 attacks, ranking vulnerabilities per 6.3.1, correcting all of them and re-evaluating after correction. The second is installing an automated technical solution in front of the applications that continually detects and prevents web attacks, is actively running and up to date, generates audit logs, and either blocks attacks or raises alerts that are immediately investigated. This assessment is not the same as the 11.3.1 and 11.3.2 scans, and the requirement was superseded by 6.4.2 as of 31 March 2025.", "remediacion_en": "1. Inventory public-facing web applications and APIs (CloudFront, ALB, API Gateway, Application Gateway, Front Door, GCP HTTP(S) load balancers). 2. Put a WAF in front of each: AWS WAF with managed rule groups (Core rule set, Known bad inputs, SQL database), Azure WAF in Prevention mode with the DRS rule set, or Cloud Armor with preconfigured WAF rules. 3. Enable WAF logging and alerts that are immediately investigated, and keep managed rules current. 4. If choosing assessments, contract annual application security testing and after significant changes, fix all findings and keep the retest. Evidence: WAF configuration and logs, or assessment reports with retest. Migrate to 6.4.2 (WAF mandatory).", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 154, "pagina_pdf_es": 165 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Distribuciones CloudFront con web ACL de AWS WAF asociada [CloudFront.6]", "Etapas de API Gateway REST asociadas a una web ACL de AWS WAF [APIGateway.4]", "Application Load Balancers con exposición a Internet sin web ACL de AWS WAF asociada (falla si existe)", "Web ACL con al menos una regla o grupo de reglas (incluye AWSManagedRulesCommonRuleSet/KnownBadInputs/SQLi) [WAF.10]", "Registro de la web ACL de AWS WAF habilitado hacia CloudWatch Logs, S3 o Firehose [WAF.11]" ], "checks_azure": [ "Application Gateway expuesto a Internet con SKU WAF_v2 o política WAF asociada (falla si no)", "Política WAF de Application Gateway/Front Door con mode = Prevention (o Detection con alerta investigada) y conjunto de reglas administradas DRS/OWASP vigente", "Diagnostic settings del WAF (ApplicationGatewayFirewallLog / FrontDoorWebApplicationFirewallLog) enviados a Log Analytics" ], "checks_gcp": [ "Backend services de balanceadores HTTP(S) externos con política de seguridad de Cloud Armor asociada (falla si no)", "Política de Cloud Armor con reglas WAF preconfiguradas (sqli, xss, lfi, rce) en acción deny", "Logging habilitado en los backend services (logConfig.enable = true) para registrar decisiones de Cloud Armor" ], "evidencia": "Kyber reporta cada punto de entrada web público con su WAF, modo de acción y registro; si se usa la vía de evaluación, el cliente aporta reportes de pruebas y retest.", "evidencia_en": "Kyber reports each public web entry point with its WAF, action mode and logging; if the assessment path is used, the customer provides test and retest reports.", "limitaciones": "No evalúa la calidad de las reglas ni la vía alternativa de evaluaciones de seguridad de aplicaciones; no ve WAF de terceros fuera de la nube (p. ej. CDN externas).", "limitaciones_en": "Does not assess rule quality or the alternative application security assessment path; cannot see third-party WAFs outside the cloud (e.g., external CDNs).", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.20", "8.26", "8.8" ], "soc2_tsc": [ "CC6.6", "CC7.1" ], "cis_controls_v8": [ "13.10", "16.13" ], "banxico_spei": [ "58a. I.B.b)" ] } }, { "id": 85, "numero_regla": "6.4.2", "requisito": "6", "seccion": "6.4", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Aplicaciones web públicas protegidas contra ataques", "seccion_titulo_en": "Public-facing web applications are protected against attacks", "descripcion_corta": "Solución técnica automatizada (WAF) que detecta y previene ataques web en aplicaciones públicas", "descripcion_larga": "Las aplicaciones web de cara al público deben contar con una solución técnica automatizada que detecte y prevenga continuamente los ataques basados en la web. Debe estar instalada frente a las aplicaciones y configurada para detectar y prevenir dichos ataques, funcionar activamente y mantenerse actualizada, generar bitácoras de auditoría, y estar configurada para bloquear los ataques o generar una alerta que se investigue de inmediato. Reemplaza al Requisito 6.4.1; fue mejor práctica hasta el 31 de marzo de 2025 y ahora es obligatorio.", "remediacion": "1. Asocie un WAF a todos los puntos de entrada web públicos: AWS WAF en CloudFront, ALB, API Gateway, AppSync y Cognito; Azure WAF en Front Door o Application Gateway; Cloud Armor en balanceadores HTTP(S) externos. 2. Active grupos de reglas administradas (OWASP/Core rule set, entradas maliciosas conocidas, SQLi, reputación de IP, Bot Control) y reglas de limitación de tasa para mitigar fuerza bruta y enumeración en flujos de pago. 3. Opere en modo de bloqueo; si alguna regla queda en conteo/detección, configure alertas (CloudWatch, Azure Monitor, Cloud Monitoring) enrutadas al SOC con investigación inmediata. 4. Habilite bitácoras completas del WAF con retención de 12 meses (10.5.1). 5. Mantenga actualizadas las versiones de reglas administradas y revise excepciones. Evidencia: asociación WAF–recurso, configuración de reglas y modo, bitácoras y alertas con tickets de investigación.", "descripcion_corta_en": "Automated technical solution (WAF) that detects and prevents web attacks on public-facing apps", "descripcion_larga_en": "Public-facing web applications must have an automated technical solution that continually detects and prevents web-based attacks. It must be installed in front of the applications and configured to detect and prevent such attacks, be actively running and kept up to date, generate audit logs, and be configured to either block attacks or raise an alert that is immediately investigated. It replaces Requirement 6.4.1; it was a best practice until 31 March 2025 and is now mandatory.", "remediacion_en": "1. Associate a WAF with every public web entry point: AWS WAF on CloudFront, ALB, API Gateway, AppSync and Cognito; Azure WAF on Front Door or Application Gateway; Cloud Armor on external HTTP(S) load balancers. 2. Enable managed rule groups (OWASP/Core rule set, known bad inputs, SQLi, IP reputation, Bot Control) and rate-based rules to mitigate brute force and enumeration on payment flows. 3. Run in blocking mode; if any rule stays in count/detection, configure alerts (CloudWatch, Azure Monitor, Cloud Monitoring) routed to the SOC for immediate investigation. 4. Enable full WAF logging with 12-month retention (10.5.1). 5. Keep managed rule versions current and review exceptions. Evidence: WAF–resource association, rule and mode configuration, logs and alerts with investigation tickets.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 156, "pagina_pdf_es": 167 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Distribuciones CloudFront con web ACL de AWS WAF asociada [CloudFront.6]", "Etapas de API Gateway REST asociadas a una web ACL de AWS WAF [APIGateway.4]", "Application Load Balancers con exposición a Internet sin web ACL de AWS WAF asociada (falla si existe)", "Web ACL con al menos una regla o grupo de reglas (incluye AWSManagedRulesCommonRuleSet/KnownBadInputs/SQLi) [WAF.10]", "Registro de la web ACL de AWS WAF habilitado hacia CloudWatch Logs, S3 o Firehose [WAF.11]", "Web ACL con regla basada en tasa (rate-based) para endpoints de autenticación y pago" ], "checks_azure": [ "Application Gateway expuesto a Internet con SKU WAF_v2 o política WAF asociada (falla si no)", "Política WAF de Application Gateway/Front Door con mode = Prevention (o Detection con alerta investigada) y conjunto de reglas administradas DRS/OWASP vigente", "Diagnostic settings del WAF (ApplicationGatewayFirewallLog / FrontDoorWebApplicationFirewallLog) enviados a Log Analytics", "Política WAF con reglas de limitación de tasa en Front Door / Application Gateway para endpoints de pago" ], "checks_gcp": [ "Backend services de balanceadores HTTP(S) externos con política de seguridad de Cloud Armor asociada (falla si no)", "Política de Cloud Armor con reglas WAF preconfiguradas (sqli, xss, lfi, rce) en acción deny", "Logging habilitado en los backend services (logConfig.enable = true) para registrar decisiones de Cloud Armor", "Política de Cloud Armor con regla de limitación de tasa (rate_based_ban/throttle) en endpoints de pago" ], "evidencia": "Kyber reporta cada punto de entrada web público con su WAF asociado, reglas administradas, modo de acción y configuración de bitácoras.", "evidencia_en": "Kyber reports each public web entry point with its associated WAF, managed rules, action mode and logging configuration.", "limitaciones": "No mide la eficacia de las reglas contra ataques reales ni confirma que las alertas se investiguen de inmediato; no ve WAF o RASP fuera de la nube del cliente.", "limitaciones_en": "Does not measure rule efficacy against real attacks or confirm alerts are investigated immediately; cannot see WAF or RASP outside the customer's cloud.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.20", "8.26" ], "soc2_tsc": [ "CC6.6", "CC7.2" ], "cis_controls_v8": [ "13.10" ], "banxico_spei": [ "58a. I.B.b)" ] } }, { "id": 86, "numero_regla": "6.4.3", "requisito": "6", "seccion": "6.4", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Aplicaciones web públicas protegidas contra ataques", "seccion_titulo_en": "Public-facing web applications are protected against attacks", "descripcion_corta": "Scripts de la página de pago autorizados, con integridad asegurada e inventario justificado", "descripcion_larga": "Todos los scripts de la página de pago que se cargan y ejecutan en el navegador del consumidor deben gestionarse así: contar con un método para confirmar que cada script está autorizado, un método para asegurar su integridad, y un inventario de todos los scripts con la justificación de negocio o técnica de por qué cada uno es necesario. Aplica a scripts propios y de terceros o cuartas partes, incluidos los de la página de la entidad que integra un formulario o iframe de pago de un TPSP; no aplica a los scripts dentro del iframe del TPSP/procesador, que son responsabilidad de este. Fue mejor práctica hasta el 31 de marzo de 2025 y ahora es obligatorio.", "remediacion": "1. Inventaríe todos los scripts de las páginas de pago (propios, de terceros y cargados dinámicamente por gestores de etiquetas) con dueño y justificación. 2. Aplique Content Security Policy restrictiva (script-src con lista permitida, nonces o hashes; frame-src/frame-ancestors para iframes de pago) mediante CloudFront response headers policies, reglas de Azure Front Door o encabezados en el backend/Cloud CDN. 3. Use Subresource Integrity (atributo integrity) en scripts estáticos y un flujo de autorización de cambios para cada script nuevo o modificado. 4. Complemente con un servicio de monitoreo de scripts del lado del cliente o reportes CSP (report-to) hacia un endpoint que alerte. 5. Si integra un iframe del procesador, obtenga su AOC que cubra 6.4.3. Evidencia: inventario con justificaciones y aprobaciones, configuración de CSP/SRI y reportes de monitoreo.", "descripcion_corta_en": "Payment page scripts authorized, integrity assured and justified in an inventory", "descripcion_larga_en": "All payment page scripts loaded and executed in the consumer's browser must be managed as follows: a method confirms each script is authorized, a method assures each script's integrity, and an inventory of all scripts is kept with a written business or technical justification for why each is needed. It applies to the entity's own and to third- and fourth-party scripts, including those on the entity's page that embeds a TPSP payment form or iframe; it does not apply to scripts inside the TPSP/processor iframe, which are that provider's responsibility. It was a best practice until 31 March 2025 and is now mandatory.", "remediacion_en": "1. Inventory all payment page scripts (first-party, third-party and those loaded dynamically by tag managers) with owner and justification. 2. Enforce a restrictive Content Security Policy (script-src allowlist, nonces or hashes; frame-src/frame-ancestors for payment iframes) through CloudFront response headers policies, Azure Front Door rules or headers at the backend/Cloud CDN. 3. Use Subresource Integrity (integrity attribute) on static scripts and a change authorization workflow for every new or modified script. 4. Complement with a client-side script monitoring service or CSP reporting (report-to) to an alerting endpoint. 5. If embedding a processor iframe, obtain its AOC covering 6.4.3. Evidence: inventory with justifications and approvals, CSP/SRI configuration and monitoring reports.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 157, "pagina_pdf_es": 168 }, "kyber_cobertura": { "tipo": "deteccion_presencia", "automatizacion": "baja", "checks_aws": [ "CloudFront: distribuciones que sirven la página de pago con response headers policy que define Content-Security-Policy (falla si no existe)", "Response headers policy con CSP sin 'unsafe-inline'/'unsafe-eval' en script-src (falla si los contiene)" ], "checks_azure": [ "Azure Front Door: rule set que agrega encabezado Content-Security-Policy a las rutas de la página de pago (falla si no existe)" ], "checks_gcp": [ "Cloud CDN / balanceador HTTP(S): customResponseHeaders con Content-Security-Policy en el backend de la página de pago (falla si no existe)" ], "evidencia": "Kyber detecta la presencia de encabezados CSP configurados en la capa de entrega de nube; el cliente aporta el inventario de scripts, justificaciones, aprobaciones y evidencia de SRI o monitoreo.", "evidencia_en": "Kyber detects the presence of CSP headers configured at the cloud delivery layer; the customer provides the script inventory, justifications, approvals and SRI or monitoring evidence.", "limitaciones": "Los scripts se ejecutan en el navegador del consumidor: el escaneo agentless no puede ver los scripts cargados, su integridad ni encabezados que la aplicación emite por sí misma.", "limitaciones_en": "Scripts run in the consumer's browser: agentless scanning cannot see loaded scripts, their integrity, or headers emitted by the application itself.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.26", "8.28", "8.32" ], "soc2_tsc": [ "CC6.8", "CC8.1" ], "cis_controls_v8": [ "2.7", "16.4" ] }, "mapeo_ucf": [ { "clave": "UCF-SDL-002", "relacion": "partial", "cobertura_pct": 50, "nota_es": "6.4.3 aplica solo a las páginas de pago y pide además inventario, autorización y justificación de cada script.", "nota_en": "6.4.3 applies only to payment pages and also requires an inventory, authorisation and justification of every script." } ] }, { "id": 87, "numero_regla": "6.5.1", "requisito": "6", "seccion": "6.5", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Cambios en los componentes del sistema gestionados de forma segura", "seccion_titulo_en": "Changes to all system components are managed securely", "descripcion_corta": "Cambios en producción gestionados según procedimientos de control de cambios", "descripcion_larga": "Los cambios a cualquier componente del sistema en el entorno de producción deben seguir procedimientos establecidos que incluyan: motivo y descripción del cambio; documentación del impacto en la seguridad; aprobación documentada por partes autorizadas; pruebas que verifiquen que el cambio no afecta negativamente la seguridad; para software a medida y personalizado, pruebas de cumplimiento con 6.2.4 antes del despliegue; y procedimientos para atender fallas y regresar a un estado seguro.", "remediacion": "1. Gestione todos los cambios de producción mediante tickets (Jira, ServiceNow) con descripción, motivo, impacto en seguridad, plan de pruebas y plan de reversión. 2. Despliegue infraestructura como código (CloudFormation, Terraform, Bicep, Deployment Manager) solo a través de pipelines con aprobación manual registrada. 3. Restrinja cambios manuales en consola en producción con SCP, Azure Policy y políticas de organización, y alerte sobre cambios fuera de pipeline usando CloudTrail/AWS Config, Activity Log y Cloud Audit Logs. 4. Ejecute pruebas de seguridad (SAST/DAST, 6.2.4) en el pipeline antes de producción. 5. Mantenga procedimientos de reversión (despliegues blue/green, snapshots). Evidencia: procedimiento, muestra de cambios rastreados desde el ticket hasta el despliegue y registros de aprobación.", "descripcion_corta_en": "Production changes managed under established change control procedures", "descripcion_larga_en": "Changes to any system component in the production environment must follow established procedures that include: reason for and description of the change; documentation of security impact; documented approval by authorized parties; testing to verify the change does not adversely affect security; for bespoke and custom software, testing for compliance with 6.2.4 before deployment; and procedures to address failures and return to a secure state.", "remediacion_en": "1. Manage every production change through tickets (Jira, ServiceNow) with description, reason, security impact, test plan and rollback plan. 2. Deploy infrastructure as code (CloudFormation, Terraform, Bicep, Deployment Manager) only through pipelines with recorded manual approval. 3. Restrict manual console changes in production with SCPs, Azure Policy and organization policies, and alert on out-of-pipeline changes using CloudTrail/AWS Config, Activity Log and Cloud Audit Logs. 4. Run security tests (SAST/DAST, 6.2.4) in the pipeline before production. 5. Maintain rollback procedures (blue/green deployments, snapshots). Evidence: procedure, sample of changes traced from ticket to deployment and approval records.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 159, "pagina_pdf_es": 170 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Procedimiento de control de cambios y muestra de cambios con ticket, aprobación, pruebas y plan de reversión; Kyber puede aportar el historial de cambios de configuración (AWS Config, Activity Log, Cloud Asset Inventory) para el muestreo.", "evidencia_en": "Change control procedure and a sample of changes with ticket, approval, testing and rollback plan; Kyber can supply configuration change history (AWS Config, Activity Log, Cloud Asset Inventory) for sampling.", "limitaciones": "El escaneo no puede verificar la aprobación, el análisis de impacto ni las pruebas de cada cambio.", "limitaciones_en": "Scanning cannot verify approval, impact analysis or testing of each change.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.32", "8.29" ], "soc2_tsc": [ "CC8.1" ], "cis_controls_v8": [ "16.1", "4.1" ], "banxico_spei": [ "58a. I.A.c).1", "58a. I.B.c)" ] }, "mapeo_ucf": [ { "clave": "UCF-CFG-002", "relacion": "equivalent", "cobertura_pct": 90 } ] }, { "id": 88, "numero_regla": "6.5.2", "requisito": "6", "seccion": "6.5", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Cambios en los componentes del sistema gestionados de forma segura", "seccion_titulo_en": "Changes to all system components are managed securely", "descripcion_corta": "Requisitos PCI DSS confirmados en sistemas nuevos o modificados tras un cambio significativo", "descripcion_larga": "Al concluir un cambio significativo, la entidad debe confirmar que todos los requisitos aplicables de PCI DSS están implementados en los sistemas y redes nuevos o modificados, y actualizar la documentación según corresponda (por ejemplo, diagramas de red y de flujo de datos, inventarios y estándares de configuración). Estos cambios significativos también deben reflejarse en la confirmación anual del alcance de PCI DSS del Requisito 12.5.2.", "remediacion": "1. Defina qué constituye un cambio significativo (nueva cuenta/suscripción/proyecto, nueva VPC/VNet, nuevo servicio que procese PAN, cambio de arquitectura). 2. Incluya en el cierre del cambio una lista de verificación PCI: configuración endurecida, antimalware, parches, bitácoras, cifrado, sin SAD almacenado y diagramas actualizados. 3. Ejecute un escaneo de Kyber sobre los recursos nuevos o modificados y adjunte el reporte de cumplimiento al ticket. 4. Ejecute los escaneos internos y externos tras el cambio (11.3.1.3 y 11.3.2.1). 5. Actualice diagramas, inventarios y la confirmación de alcance. Evidencia: tickets de cambio significativo con lista de verificación, reporte de Kyber posterior y documentación actualizada.", "descripcion_corta_en": "PCI DSS requirements confirmed on new or changed systems after a significant change", "descripcion_larga_en": "Upon completing a significant change, the entity must confirm that all applicable PCI DSS requirements are in place on new or changed systems and networks, and update documentation as applicable (for example, network and data-flow diagrams, inventories and configuration standards). These significant changes should also be reflected in the annual PCI DSS scope confirmation under Requirement 12.5.2.", "remediacion_en": "1. Define what counts as a significant change (new account/subscription/project, new VPC/VNet, new service processing PAN, architecture change). 2. Include a PCI checklist at change closure: hardened configuration, anti-malware, patches, logging, encryption, no stored SAD and updated diagrams. 3. Run a Kyber scan on new or changed resources and attach the compliance report to the ticket. 4. Run internal and external scans after the change (11.3.1.3 and 11.3.2.1). 5. Update diagrams, inventories and scope confirmation. Evidence: significant change tickets with checklist, post-change Kyber report and updated documentation.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 160, "pagina_pdf_es": 171 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Recursos creados o modificados en las cuentas del CDE (AWS Config / CloudTrail) evaluados contra el catálogo PCI DSS de Kyber tras el cambio", "Nuevas cuentas de AWS Organizations incorporadas a GuardDuty, Security Hub, CloudTrail organizacional y Config (falla si alguna falta)" ], "checks_azure": [ "Nuevas suscripciones bajo el grupo de administración del CDE con Defender for Cloud, diagnostic settings y Azure Policy asignados (falla si alguna falta)" ], "checks_gcp": [ "Nuevos proyectos en la carpeta del CDE con SCC, Cloud Audit Logs y políticas de organización heredadas (falla si alguno falta)" ], "evidencia": "Kyber genera el reporte de cumplimiento posterior al cambio para los recursos nuevos o modificados y diagramas/inventarios actualizados.", "evidencia_en": "Kyber generates the post-change compliance report for new or changed resources and updated diagrams/inventories.", "limitaciones": "Kyber no determina qué cambios son significativos ni cubre requisitos de proceso o componentes fuera de la nube.", "limitaciones_en": "Kyber does not determine which changes are significant nor cover process requirements or components outside the cloud.", "responsabilidad_compartida": "cliente", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.32", "5.9" ], "soc2_tsc": [ "CC8.1", "CC3.4" ], "cis_controls_v8": [ "4.1", "1.1" ] } }, { "id": 89, "numero_regla": "6.5.3", "requisito": "6", "seccion": "6.5", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Cambios en los componentes del sistema gestionados de forma segura", "seccion_titulo_en": "Changes to all system components are managed securely", "descripcion_corta": "Entornos de preproducción separados de producción con controles de acceso", "descripcion_larga": "Los entornos de preproducción (desarrollo, pruebas, aceptación de usuarios, etc.) deben estar separados de los de producción, y dicha separación debe aplicarse mediante controles de acceso. Incluso si se usa infraestructura de producción para pruebas o desarrollo, la separación lógica o física debe impedir que vulnerabilidades introducidas por actividades de preproducción afecten a producción.", "remediacion": "1. Separe producción y no producción en cuentas AWS, suscripciones Azure y proyectos GCP distintos, agrupados en OU, grupos de administración y carpetas diferentes. 2. Evite conectividad directa: sin VPC peering, rutas de Transit Gateway, VNet peering ni Shared VPC entre entornos; si existe un servicio compartido, controle con NSC el tráfico mínimo. 3. Aplique controles de acceso: roles y grupos IAM distintos por entorno, sin relaciones de confianza que permitan a identidades de no producción asumir roles de producción, y SCP/políticas de organización específicas. 4. Etiquete cada cuenta/suscripción/proyecto con su entorno. Evidencia: estructura organizacional, configuración de red sin conectividad entre entornos y políticas de acceso.", "descripcion_corta_en": "Pre-production environments separated from production with access controls", "descripcion_larga_en": "Pre-production environments (development, testing, user acceptance, etc.) must be separated from production environments, and the separation must be enforced with access controls. Even when production infrastructure is used for testing or development, logical or physical separation must prevent vulnerabilities introduced by pre-production activities from affecting production.", "remediacion_en": "1. Separate production and non-production into distinct AWS accounts, Azure subscriptions and GCP projects, grouped under different OUs, management groups and folders. 2. Avoid direct connectivity: no VPC peering, Transit Gateway routes, VNet peering or Shared VPC between environments; if a shared service exists, restrict traffic to the minimum with NSCs. 3. Enforce access controls: distinct IAM roles and groups per environment, no trust relationships allowing non-production identities to assume production roles, and environment-specific SCPs/organization policies. 4. Tag every account/subscription/project with its environment. Evidence: organizational structure, network configuration without cross-environment connectivity and access policies.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 161, "pagina_pdf_es": 172 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Cuentas de producción y no producción en OU distintas de AWS Organizations (falla si comparten cuenta u OU)", "VPC peering o adjuntos/rutas de Transit Gateway entre VPC de producción y no producción (falla si existe)", "Roles IAM de producción con política de confianza que permite principales de cuentas de no producción (falla si existe)", "Cuentas sin etiqueta de entorno (Environment) definida (falla si existe)" ], "checks_azure": [ "Suscripciones de producción y no producción bajo grupos de administración distintos (falla si comparten suscripción)", "VNet peering entre VNet de producción y no producción (falla si existe)", "Identidades con roles Owner/Contributor asignados simultáneamente en suscripciones de producción y no producción (falla si existen fuera del grupo de plataforma)" ], "checks_gcp": [ "Proyectos de producción y no producción en carpetas distintas de la organización", "VPC Network Peering o Shared VPC que conecte redes de producción y no producción (falla si existe)", "Cuentas de servicio de proyectos de no producción con roles IAM en proyectos de producción (falla si existen)" ], "evidencia": "Kyber genera el mapa de cuentas/suscripciones/proyectos por entorno y reporta conectividad y relaciones de confianza entre producción y no producción.", "evidencia_en": "Kyber generates the map of accounts/subscriptions/projects by environment and reports connectivity and trust relationships between production and non-production.", "limitaciones": "Depende de que el cliente etiquete o declare correctamente los entornos; no ve separación en sistemas fuera de la nube.", "limitaciones_en": "Depends on the customer correctly tagging or declaring environments; it cannot see separation in systems outside the cloud.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.31", "8.22" ], "soc2_tsc": [ "CC8.1", "CC6.1" ], "cis_controls_v8": [ "16.8", "12.2" ], "banxico_spei": [ "58a. I.B.a)" ] } }, { "id": 90, "numero_regla": "6.5.4", "requisito": "6", "seccion": "6.5", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Cambios en los componentes del sistema gestionados de forma segura", "seccion_titulo_en": "Changes to all system components are managed securely", "descripcion_corta": "Roles y funciones separados entre producción y preproducción para desplegar solo cambios aprobados", "descripcion_larga": "Los roles y funciones deben separarse entre los entornos de producción y preproducción para garantizar la rendición de cuentas, de modo que únicamente se desplieguen cambios revisados y aprobados. En organizaciones pequeñas donde una persona cumple varios roles, el mismo objetivo puede lograrse con controles de procedimiento adicionales; por ejemplo, un desarrollador puede usar una cuenta privilegiada en desarrollo y una cuenta separada con acceso de nivel usuario en producción.", "remediacion": "1. Restrinja el despliegue a producción a identidades de pipeline (roles de CI/CD, identidades administradas, cuentas de servicio) que solo actúan tras aprobación. 2. Evite que los desarrolladores tengan permisos de escritura en producción: conjuntos de permisos de IAM Identity Center, roles RBAC y grupos IAM de GCP diferenciados por entorno, con acceso privilegiado temporal (just-in-time) mediante Azure PIM, aprobación de acceso temporal en IAM Identity Center o Privileged Access Manager de GCP. 3. Si una persona tiene varios roles, use cuentas separadas por entorno y registre su actividad. 4. Revise trimestralmente las asignaciones. Evidencia: matriz de roles por entorno, configuración de permisos y del pipeline, y registros de aprobación de despliegues.", "descripcion_corta_en": "Roles and functions separated between production and pre-production so only approved changes deploy", "descripcion_larga_en": "Roles and functions must be separated between production and pre-production environments to provide accountability, so that only reviewed and approved changes are deployed. In small organizations where individuals hold several roles, the same goal can be achieved with additional procedural controls; for example, a developer may use a privileged account in development and a separate user-level account in production.", "remediacion_en": "1. Restrict production deployment to pipeline identities (CI/CD roles, managed identities, service accounts) that act only after approval. 2. Prevent developers from having write permissions in production: IAM Identity Center permission sets, RBAC roles and GCP IAM groups differentiated by environment, with just-in-time privileged access through Azure PIM, IAM Identity Center temporary elevated access or GCP Privileged Access Manager. 3. Where a person holds multiple roles, use separate accounts per environment and log their activity. 4. Review assignments quarterly. Evidence: per-environment role matrix, permission and pipeline configuration, and deployment approval records.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 162, "pagina_pdf_es": 173 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Usuarios o grupos humanos con permisos de escritura/administración en cuentas de producción que también los tienen en cuentas de desarrollo (falla si existen sin justificación)", "Conjuntos de permisos de IAM Identity Center con AdministratorAccess asignados de forma permanente en cuentas de producción (falla si existen)", "Despliegues en producción realizados por identidades humanas en lugar del rol del pipeline según CloudTrail (falla si existen)" ], "checks_azure": [ "Asignaciones permanentes (no elegibles en PIM) de Owner/Contributor a usuarios en suscripciones de producción (falla si existen)", "Usuarios con roles de escritura simultáneos en suscripciones de producción y desarrollo (falla si existen sin justificación)" ], "checks_gcp": [ "Usuarios con roles/owner o roles/editor en proyectos de producción (falla si existen fuera del grupo de plataforma)", "Despliegues en producción hechos por cuentas de usuario y no por la cuenta de servicio del pipeline según Cloud Audit Logs" ], "evidencia": "Kyber genera la matriz efectiva de permisos por identidad y entorno para revisión; el cliente aporta la política de separación de funciones y aprobaciones de despliegue.", "evidencia_en": "Kyber generates the effective permission matrix per identity and environment for review; the customer provides the segregation of duties policy and deployment approvals.", "limitaciones": "No puede verificar los controles de procedimiento compensatorios ni la revisión y aprobación efectiva de cada cambio.", "limitaciones_en": "Cannot verify compensating procedural controls or the actual review and approval of each change.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.3", "8.31", "8.2" ], "soc2_tsc": [ "CC6.1", "CC6.3", "CC8.1" ], "cis_controls_v8": [ "6.8", "5.4", "16.8" ], "banxico_spei": [ "58a. I.B.a)" ] } }, { "id": 91, "numero_regla": "6.5.5", "requisito": "6", "seccion": "6.5", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Cambios en los componentes del sistema gestionados de forma segura", "seccion_titulo_en": "Changes to all system components are managed securely", "descripcion_corta": "Sin PAN activos en entornos de preproducción fuera del CDE", "descripcion_larga": "No deben usarse números de cuenta principal (PAN) activos en entornos de preproducción, salvo que esos entornos formen parte del CDE y estén protegidos conforme a todos los requisitos aplicables de PCI DSS. Los PAN activos son los válidos emitidos por o en nombre de una marca de pago; la entidad es responsable de confirmar que un PAN no está activo antes de excluirlo del alcance.", "remediacion": "1. Establezca en la política que las pruebas usan solo PAN de prueba de las marcas o del procesador, o datos tokenizados/sintéticos. 2. Prohíba copiar respaldos o snapshots de bases de datos de producción a cuentas/suscripciones/proyectos de no producción; si se requiere, aplique enmascaramiento irreversible antes de compartir. 3. Ejecute descubrimiento de datos sensibles en no producción: Amazon Macie con identificador CREDIT_CARD_NUMBER, Microsoft Purview / Defender for Storage sensitive data discovery y GCP Sensitive Data Protection (perfiles de descubrimiento), y escale cualquier hallazgo. 4. Bloquee el uso compartido de snapshots y AMI de producción hacia cuentas de no producción. Evidencia: política, configuración de descubrimiento, resultados sin PAN activos y procedimiento de enmascaramiento.", "descripcion_corta_en": "No live PANs in pre-production environments outside the CDE", "descripcion_larga_en": "Live primary account numbers (PANs) must not be used in pre-production environments, unless those environments are part of the CDE and protected per all applicable PCI DSS requirements. Live PANs are valid PANs issued by or on behalf of a payment brand; the entity is responsible for confirming a PAN is not live before excluding it from scope.", "remediacion_en": "1. State in policy that testing uses only brand or processor test PANs, or tokenized/synthetic data. 2. Prohibit copying production database backups or snapshots to non-production accounts/subscriptions/projects; if needed, apply irreversible masking before sharing. 3. Run sensitive data discovery in non-production: Amazon Macie with the CREDIT_CARD_NUMBER identifier, Microsoft Purview / Defender for Storage sensitive data discovery and GCP Sensitive Data Protection (discovery profiles), and escalate any finding. 4. Block sharing of production snapshots and AMIs to non-production accounts. Evidence: policy, discovery configuration, results with no live PANs and masking procedure.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 163, "pagina_pdf_es": 174 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Amazon Macie habilitado con descubrimiento automatizado de datos sensibles en cuentas de no producción; hallazgos SensitiveData:S3Object/Financial (falla si existen)", "Snapshots de RDS/EBS o AMI de cuentas de producción compartidos con cuentas de no producción (falla si existen)", "Kyber: patrones de PAN válidos por Luhn en volúmenes de instancias de no producción a partir de snapshots (falla si existen)" ], "checks_azure": [ "Defender for Storage con sensitive data threat detection o Microsoft Purview escaneando cuentas de almacenamiento de no producción; hallazgos de tarjetas de crédito (falla si existen)", "Snapshots o copias de bases de datos de producción restauradas en suscripciones de no producción (falla si existen)" ], "checks_gcp": [ "Sensitive Data Protection con perfiles de descubrimiento en proyectos de no producción; infoType CREDIT_CARD_NUMBER detectado (falla si existe)", "Imágenes o snapshots de discos de proyectos de producción compartidos con proyectos de no producción (falla si existen)" ], "evidencia": "Kyber reporta hallazgos de PAN en almacenamiento y snapshots de no producción y el uso compartido de respaldos de producción; el cliente aporta la política y procedimiento de enmascaramiento.", "evidencia_en": "Kyber reports PAN findings in non-production storage and snapshots and sharing of production backups; the customer provides the policy and masking procedure.", "limitaciones": "No distingue PAN activos de PAN de prueba válidos por Luhn; las bases de datos administradas y los datos dentro de aplicaciones solo se cubren si se exportan o escanean.", "limitaciones_en": "Cannot distinguish live PANs from Luhn-valid test PANs; managed databases and in-application data are covered only if exported or scanned.", "responsabilidad_compartida": "cliente", "capacidades_pendientes": [ "deteccion_pan_en_snapshots" ], "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.33", "8.31", "8.11" ], "soc2_tsc": [ "CC6.1", "C1.1" ], "cis_controls_v8": [ "3.2", "16.8" ] } }, { "id": 92, "numero_regla": "6.5.6", "requisito": "6", "seccion": "6.5", "categoria": "Requisito 6: Desarrollar y mantener sistemas y software seguros", "categoria_en": "Requirement 6: Develop and Maintain Secure Systems and Software", "seccion_titulo": "Cambios en los componentes del sistema gestionados de forma segura", "seccion_titulo_en": "Changes to all system components are managed securely", "descripcion_corta": "Datos y cuentas de prueba eliminados antes de pasar a producción", "descripcion_larga": "Los datos de prueba y las cuentas de prueba deben eliminarse de los componentes del sistema antes de que estos entren en producción. Esta información puede revelar el funcionamiento de una aplicación o sistema y facilitar su compromiso. Aplica tanto al software comercial como a las aplicaciones desarrolladas internamente.", "remediacion": "1. Incluya en la lista de verificación de paso a producción la eliminación de cuentas, credenciales y datos de prueba en aplicaciones, bases de datos, sistemas operativos e IAM. 2. Use convenciones de nombres para identificar cuentas de prueba (test, demo, qa, tmp) y automatice su detección en producción. 3. Construya imágenes de producción limpias (golden AMI, Azure Compute Gallery, imágenes personalizadas de GCP) sin usuarios ni datos de prueba. 4. Revise después de cada instalación o actualización de software comercial que no queden cuentas de demostración. Evidencia: listas de verificación firmadas, reportes de búsqueda de cuentas de prueba en producción y procedimiento de construcción de imágenes.", "descripcion_corta_en": "Test data and test accounts removed before going into production", "descripcion_larga_en": "Test data and test accounts must be removed from system components before the system goes into production. Such information can reveal how an application or system works and facilitate its compromise. It applies to both off-the-shelf software and in-house applications.", "remediacion_en": "1. Include in the go-live checklist the removal of test accounts, credentials and data in applications, databases, operating systems and IAM. 2. Use naming conventions to identify test accounts (test, demo, qa, tmp) and automate their detection in production. 3. Build clean production images (golden AMI, Azure Compute Gallery, GCP custom images) without test users or data. 4. After each off-the-shelf software installation or update, verify no demo accounts remain. Evidence: signed checklists, reports of test account searches in production and image build procedure.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 164, "pagina_pdf_es": 175 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Usuarios, roles o access keys IAM en cuentas de producción con nombres que coinciden con test|demo|qa|tmp (falla si existen)", "Kyber: cuentas locales del SO con nombres de prueba en snapshots de instancias de producción (falla si existen)", "Recursos en cuentas de producción con etiqueta Environment de prueba (falla si existen)" ], "checks_azure": [ "Usuarios de Entra ID o principales de servicio con nombres de prueba con roles en suscripciones de producción (falla si existen)", "Kyber: cuentas locales del SO con nombres de prueba en snapshots de VM de producción (falla si existen)" ], "checks_gcp": [ "Cuentas de servicio o miembros IAM con nombres de prueba en proyectos de producción (falla si existen)", "Kyber: cuentas locales del SO con nombres de prueba en snapshots de VM de producción (falla si existen)" ], "evidencia": "Kyber reporta identidades y cuentas locales con patrones de prueba en producción; el cliente aporta las listas de verificación de paso a producción.", "evidencia_en": "Kyber reports identities and local accounts with test patterns in production; the customer provides go-live checklists.", "limitaciones": "La detección se basa en convenciones de nombres; no identifica datos de prueba dentro de bases de datos ni cuentas dentro de las aplicaciones.", "limitaciones_en": "Detection relies on naming conventions; it cannot identify test data inside databases or accounts within applications.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.33", "8.31", "5.18" ], "soc2_tsc": [ "CC6.2", "CC8.1" ], "cis_controls_v8": [ "5.1", "5.3", "16.8" ] } }, { "id": 93, "numero_regla": "7.1.1", "requisito": "7", "seccion": "7.1", "categoria": "Requisito 7: Restringir el acceso a los componentes del sistema y a los datos de tarjetahabiente según la necesidad de conocer del negocio", "categoria_en": "Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know", "seccion_titulo": "Procesos y mecanismos de restricción de acceso definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for access restriction are defined and understood", "descripcion_corta": "Políticas y procedimientos del Requisito 7 documentados, vigentes, en uso y comunicados", "descripcion_larga": "Las políticas de seguridad y los procedimientos operativos que exige el Requisito 7 (restricción del acceso por necesidad de conocer) deben estar por escrito, mantenerse actualizados, aplicarse en la práctica y ser conocidos por todas las partes involucradas. El objetivo es que las expectativas, controles y supervisión de estas actividades estén definidos y que el personal los siga de forma repetible y conforme a la intención de la gerencia. Se recomienda actualizar los documentos en cuanto ocurra un cambio de proceso, tecnología u objetivo de negocio, y no solo en el ciclo periódico.", "remediacion": "1) Redacta una política de restricción del acceso por necesidad de conocer y sus procedimientos operativos, incluyendo cómo se aplican en las cuentas y organizaciones de nube (AWS Organizations/IAM Identity Center, Azure Entra ID/RBAC, GCP Cloud Identity/IAM). 2) Asigna un dueño del documento, control de versiones y fecha de revisión al menos anual y tras cada cambio relevante. 3) Publica los documentos en un repositorio accesible y registra el acuse de lectura del personal afectado (administradores de nube, DevOps, seguridad, terceros). 4) Verifica que los procedimientos reflejen la operación real (por ejemplo, que el flujo de alta de accesos descrito coincida con el que se usa). 5) Conserva como evidencia para el QSA: documento aprobado con historial de versiones, constancias de difusión/acuse y entrevistas que confirmen su uso.", "descripcion_corta_en": "Requirement 7 policies and procedures documented, current, in use and communicated", "descripcion_larga_en": "The security policies and operational procedures required by Requirement 7 (restricting access by business need to know) must be written down, kept current, actually followed, and known to every affected party. The intent is that expectations, controls and oversight for these activities are defined and that staff carry them out repeatably and in line with management's intent. Documents should be updated as soon as processes, technologies or business objectives change, not only on a periodic cycle.", "remediacion_en": "1) Write a restricting access by business need to know policy and supporting operational procedures, including how they apply to cloud accounts and organizations (AWS Organizations/IAM Identity Center, Azure Entra ID/RBAC, GCP Cloud Identity/IAM). 2) Assign a document owner, version control and a review date at least annually and after any significant change. 3) Publish the documents in an accessible repository and record read acknowledgments from affected staff (cloud administrators, DevOps, security, third parties). 4) Confirm procedures match real operations (e.g., the documented access-request flow is the one actually used). 5) Keep as QSA evidence: approved document with version history, dissemination/acknowledgment records and interviews confirming use.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 166, "pagina_pdf_es": 177 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Política y procedimientos del Requisito 7 aprobados y versionados (Kyber puede generar la plantilla con el generador de políticas), registros de difusión y acuse de lectura del personal.", "evidencia_en": "Approved, versioned Requirement 7 policy and procedures (Kyber's policy generator can produce the template), plus dissemination and read-acknowledgment records.", "limitaciones": "El escaneo de nube no puede comprobar que las políticas estén vigentes, en uso ni que el personal las conozca.", "limitaciones_en": "Cloud scanning cannot confirm that policies are current, in use or known to staff.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.1", "5.37", "5.15" ], "soc2_tsc": [ "CC1.3", "CC2.2", "CC5.3" ], "cis_controls_v8": [ "6.1" ] } }, { "id": 94, "numero_regla": "7.1.2", "requisito": "7", "seccion": "7.1", "categoria": "Requisito 7: Restringir el acceso a los componentes del sistema y a los datos de tarjetahabiente según la necesidad de conocer del negocio", "categoria_en": "Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know", "seccion_titulo": "Procesos y mecanismos de restricción de acceso definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for access restriction are defined and understood", "descripcion_corta": "Roles y responsabilidades del Requisito 7 documentados, asignados y comprendidos", "descripcion_larga": "Las funciones y responsabilidades para ejecutar las actividades del Requisito 7 (restricción del acceso por necesidad de conocer) deben estar documentadas, asignadas a personas concretas y ser entendidas por ellas. Se busca que las tareas cotidianas estén repartidas y que el personal rinda cuentas de la operación continua y exitosa de estos controles. Pueden documentarse dentro de las políticas o en documentos aparte, por ejemplo con una matriz RACI y con el acuse de aceptación de cada responsable.", "remediacion": "1) Elabora una matriz RACI para las actividades del Requisito 7 (restricción del acceso por necesidad de conocer) en la nube: quién solicita, aprueba, otorga, revisa y revoca accesos en AWS IAM/Identity Center, Azure Entra ID/RBAC y GCP IAM. 2) Asigna nombres o puestos concretos, incluidos suplentes y terceros (por ejemplo, el proveedor de servicios administrados). 3) Obtén el acuse firmado o electrónico de cada responsable y repítelo cuando cambien funciones o personal. 4) Revisa la matriz al menos una vez al año y tras reorganizaciones. 5) Evidencia para el QSA: matriz RACI aprobada, descripciones de puesto y acuses, más entrevistas en las que el personal describa sus responsabilidades.", "descripcion_corta_en": "Requirement 7 roles and responsibilities documented, assigned and understood", "descripcion_larga_en": "Roles and responsibilities for carrying out the activities in Requirement 7 (restricting access by business need to know) must be documented, assigned to specific people, and understood by them. The aim is that day-to-day duties are allocated and staff are accountable for the continuous, successful operation of these controls. They may be documented within policies or in separate documents, for example a RACI matrix with each owner's acknowledgment.", "remediacion_en": "1) Build a RACI matrix for Requirement 7 activities (restricting access by business need to know) in the cloud: who requests, approves, grants, reviews and revokes access in AWS IAM/Identity Center, Azure Entra ID/RBAC and GCP IAM. 2) Assign named people or positions, including backups and third parties (e.g., a managed service provider). 3) Collect signed or electronic acknowledgment from each owner and repeat it when roles or staff change. 4) Review the matrix at least annually and after reorganizations. 5) QSA evidence: approved RACI matrix, job descriptions and acknowledgments, plus interviews in which staff describe their responsibilities.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 167, "pagina_pdf_es": 178 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Matriz RACI o documento de roles del Requisito 7 aprobado, con acuses de los responsables.", "evidencia_en": "Approved RACI matrix or roles document for Requirement 7, with owners' acknowledgments.", "limitaciones": "El escaneo no puede verificar que los roles estén asignados ni que el personal los comprenda.", "limitaciones_en": "Scanning cannot verify that roles are assigned or understood by staff.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.2", "5.15" ], "soc2_tsc": [ "CC1.3", "CC5.3" ], "cis_controls_v8": [ "6.1" ] } }, { "id": 95, "numero_regla": "7.2.1", "requisito": "7", "seccion": "7.2", "categoria": "Requisito 7: Restringir el acceso a los componentes del sistema y a los datos de tarjetahabiente según la necesidad de conocer del negocio", "categoria_en": "Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know", "seccion_titulo": "Acceso a componentes y datos definido y asignado adecuadamente", "seccion_titulo_en": "Access to system components and data is appropriately defined and assigned", "descripcion_corta": "Modelo de control de acceso definido por función laboral y mínimo privilegio", "descripcion_larga": "La entidad debe definir un modelo de control de acceso que otorgue el acceso adecuado según sus necesidades de negocio y de acceso, que se base en la clasificación y funciones del puesto de cada usuario para acceder a componentes del sistema y recursos de datos, y que conceda solo los privilegios mínimos necesarios (por ejemplo, usuario o administrador) para desempeñar la función. El modelo identifica los recursos a proteger, las funciones laborales que requieren acceso y las actividades que cada función puede realizar (lectura, escritura, consulta). Pueden usarse modelos como RBAC o ABAC y se recomienda considerar la separación de funciones.", "remediacion": "1) Define un catálogo de funciones laborales (p. ej., administrador de red, DBA, desarrollador, soporte, auditor) y, para cada una, los recursos del CDE y las acciones permitidas. 2) Implementa el modelo como roles: AWS IAM Identity Center permission sets por función y cuenta; Azure RBAC con roles personalizados asignados a grupos de Entra ID en el alcance mínimo (grupo de recursos, no suscripción); GCP roles predefinidos o personalizados asignados a grupos de Google en proyecto o recurso. 3) Prohíbe roles amplios: políticas AWS con Action \"*\" y Resource \"*\", Owner/Contributor a nivel suscripción en Azure y roles básicos Owner/Editor en GCP para personas. 4) Aplica separación de funciones (quien administra accesos no administra bitácoras de auditoría). 5) Usa SCP (AWS), Azure Policy y Organization Policies (GCP) como límites preventivos. 6) Evidencia: documento del modelo, matriz rol-permiso y exportación de la configuración que la respalde.", "descripcion_corta_en": "Access control model defined by job function and least privilege", "descripcion_larga_en": "The entity must define an access control model that grants access appropriate to its business and access needs, bases access to system components and data resources on each user's job classification and function, and grants only the least privileges (e.g., user versus administrator) needed for the job. The model identifies the resources to protect, the job functions needing access, and the activities each function may perform (read, write, query). Models such as RBAC or ABAC may be used, and separation of duties should be considered.", "remediacion_en": "1) Define a catalog of job functions (e.g., network admin, DBA, developer, support, auditor) and, for each, the CDE resources and allowed actions. 2) Implement the model as roles: AWS IAM Identity Center permission sets per function and account; Azure RBAC custom roles assigned to Entra ID groups at the narrowest scope (resource group, not subscription); GCP predefined or custom roles granted to Google groups at project or resource level. 3) Prohibit broad roles: AWS policies with Action \"*\" and Resource \"*\", Owner/Contributor at Azure subscription scope, and GCP basic Owner/Editor roles for humans. 4) Enforce separation of duties (those administering access do not administer audit logs). 5) Use SCPs (AWS), Azure Policy and Organization Policies (GCP) as preventive guardrails. 6) Evidence: model document, role-permission matrix and configuration exports supporting it.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 168, "pagina_pdf_es": 179 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Inventario de permission sets de IAM Identity Center, roles y políticas IAM por cuenta, con las acciones y recursos que conceden (matriz rol-permiso)", "Políticas IAM administradas por el cliente con Action \"*\" y Resource \"*\" adjuntas a usuarios, grupos o roles (falla si existe) [IAM.1]", "AWS Organizations: existencia de SCP que restrinjan acciones de alto riesgo en las cuentas del CDE" ], "checks_azure": [ "Inventario de asignaciones RBAC (principal, rol, alcance) en grupos de administración, suscripciones y grupos de recursos", "Roles personalizados de Azure con Actions \"*\" en alcance de suscripción o grupo de administración (falla si existe)", "Asignaciones de Owner o Contributor a usuarios individuales en alcance de suscripción (falla si existe)" ], "checks_gcp": [ "Inventario de bindings de IAM (miembro, rol, recurso) en organización, carpetas y proyectos", "Roles básicos roles/owner o roles/editor otorgados a usuarios en proyectos del CDE (falla si existe)", "Bindings otorgados directamente a cuentas user: en lugar de grupos (alerta)" ], "evidencia": "Kyber genera la matriz rol-permiso-recurso a partir de IAM/RBAC de las tres nubes; el cliente aporta el documento del modelo de control de acceso aprobado y la justificación de negocio de cada rol.", "evidencia_en": "Kyber generates the role-permission-resource matrix from IAM/RBAC across the three clouds; the customer provides the approved access control model document and the business justification for each role.", "limitaciones": "El escaneo muestra los permisos configurados, pero no puede saber si corresponden a las funciones laborales reales ni a la necesidad de negocio; tampoco cubre permisos dentro de sistemas operativos, bases de datos o aplicaciones.", "limitaciones_en": "Scanning shows configured permissions but cannot determine whether they match real job functions or business need; it does not cover permissions inside operating systems, databases or applications.", "responsabilidad_compartida": "cliente", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.15", "5.3", "8.2", "8.3" ], "soc2_tsc": [ "CC6.1", "CC6.3" ], "cis_controls_v8": [ "6.8", "3.3" ], "banxico_spei": [ "58a. I.A.e).1", "58a. I.A.e).4" ] }, "mapeo_ucf": [ { "clave": "UCF-IAM-002", "relacion": "equivalent", "cobertura_pct": 90 } ] }, { "id": 96, "numero_regla": "7.2.2", "requisito": "7", "seccion": "7.2", "categoria": "Requisito 7: Restringir el acceso a los componentes del sistema y a los datos de tarjetahabiente según la necesidad de conocer del negocio", "categoria_en": "Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know", "seccion_titulo": "Acceso a componentes y datos definido y asignado adecuadamente", "seccion_titulo_en": "Access to system components and data is appropriately defined and assigned", "descripcion_corta": "Acceso de usuarios, incluidos privilegiados, asignado por función y mínimo privilegio", "descripcion_larga": "El acceso de todos los usuarios, incluidos los privilegiados, debe asignarse con base en la clasificación y función de su puesto y limitarse a los privilegios mínimos necesarios para cumplir sus responsabilidades. Así se evita que usuarios sin conocimiento suficiente modifiquen configuraciones o ajustes de seguridad por error, y se reduce el daño si un ID de usuario se ve comprometido. Los privilegios administrativos deben ser específicos a la tarea (p. ej., un administrador de respaldos no debe tener los mismos privilegios que el administrador general) y puede considerarse la gestión de acceso privilegiado (PAM) para conceder privilegios solo cuando se necesitan.", "remediacion": "1) Asigna accesos a personas únicamente mediante grupos/roles del modelo definido en 7.2.1, nunca permisos ad hoc. 2) AWS: usa IAM Identity Center con permission sets de alcance acotado; elimina AdministratorAccess de usuarios cotidianos; usa IAM Access Analyzer (accesos no usados y generación de políticas a partir de CloudTrail) para recortar permisos. 3) Azure: elimina asignaciones permanentes de Owner/Contributor/User Access Administrator a nivel suscripción; habilita Entra ID PIM para elevación justo a tiempo con aprobación y límite de duración; limita Global Administrator a menos de 5 cuentas. 4) GCP: reemplaza roles básicos Owner/Editor por roles predefinidos o personalizados; aplica las recomendaciones de IAM Recommender; usa IAM Conditions o acceso temporal (PAM de Google Cloud) para privilegios elevados. 5) Separa cuentas administrativas de cuentas de uso diario. 6) Evidencia: exportación de asignaciones por usuario contrastada con su puesto y reportes de Access Analyzer/Recommender/PIM.", "descripcion_corta_en": "User access, including privileged users, assigned by job function and least privilege", "descripcion_larga_en": "Access for all users, including privileged users, must be assigned based on job classification and function and limited to the least privileges needed to carry out their responsibilities. This prevents users lacking sufficient knowledge from mistakenly changing configurations or security settings, and limits damage if a user ID is compromised. Administrative privileges should be task-specific (e.g., a backup administrator should not hold the same privileges as the overall systems administrator), and privileged access management (PAM) can be used to grant privileges only while needed.", "remediacion_en": "1) Assign human access only through groups/roles from the model defined in 7.2.1, never ad hoc permissions. 2) AWS: use IAM Identity Center with narrowly scoped permission sets; remove AdministratorAccess from everyday users; use IAM Access Analyzer (unused access and CloudTrail-based policy generation) to trim permissions. 3) Azure: remove standing Owner/Contributor/User Access Administrator assignments at subscription scope; enable Entra ID PIM for just-in-time elevation with approval and time limits; keep Global Administrator to fewer than 5 accounts. 4) GCP: replace basic Owner/Editor roles with predefined or custom roles; apply IAM Recommender findings; use IAM Conditions or temporary access (Google Cloud PAM) for elevated privileges. 5) Separate admin accounts from daily-use accounts. 6) Evidence: per-user assignment export compared with job role, and Access Analyzer/Recommender/PIM reports.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 170, "pagina_pdf_es": 181 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Políticas IAM con Action \"*\" sobre Resource \"*\" (\"*:*\") adjuntas a usuarios, grupos o roles (falla si existe) [IAM.1]", "Políticas administradas por el cliente que permiten acciones comodín por servicio, p. ej. \"s3:*\" (falla si existe) [IAM.21]", "Usuarios o permission sets con AdministratorAccess fuera del grupo administrativo autorizado (falla si existe)", "IAM Access Analyzer de accesos no usados habilitado; permisos y roles no usados en más de 90 días (falla si existen)", "Llaves de acceso activas en la cuenta root (falla si existe) [IAM.4]" ], "checks_azure": [ "Asignaciones permanentes de Owner, Contributor o User Access Administrator a usuarios en alcance de suscripción o grupo de administración (falla si existen fuera de PIM)", "Entra ID: número de Global Administrators mayor a 4 o menor a 2 (falla)", "Entra ID PIM: roles privilegiados configurados como elegibles con aprobación y duración máxima, sin asignaciones activas permanentes", "Roles personalizados con Actions \"*\" (falla si existe)" ], "checks_gcp": [ "Roles básicos roles/owner o roles/editor asignados a usuarios humanos en proyectos, carpetas u organización (falla si existe)", "Recomendaciones activas de IAM Recommender para quitar permisos en exceso en proyectos del CDE (falla si existen sin atender)", "roles/resourcemanager.organizationAdmin o roles/iam.securityAdmin asignados a usuarios fuera del grupo autorizado (falla si existe)" ], "evidencia": "Kyber genera el listado de usuarios con privilegios administrativos y los hallazgos de permisos excesivos/no usados; el cliente aporta la correspondencia de cada usuario con su puesto y la justificación de los privilegios.", "evidencia_en": "Kyber generates the list of users with administrative privileges and excessive/unused permission findings; the customer provides each user's mapping to job role and justification for privileges.", "limitaciones": "El escaneo detecta privilegios amplios o no usados, pero no puede confirmar que los privilegios restantes sean los mínimos para el puesto de cada persona; no cubre cuentas locales de SO, bases de datos ni aplicaciones.", "limitaciones_en": "Scanning detects broad or unused privileges but cannot confirm the remaining privileges are the minimum for each person's job; it does not cover local OS, database or application accounts.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.15", "5.18", "8.2" ], "soc2_tsc": [ "CC6.1", "CC6.3" ], "cis_controls_v8": [ "5.4", "6.8" ], "banxico_spei": [ "58a. I.A.e).1" ] } }, { "id": 97, "numero_regla": "7.2.3", "requisito": "7", "seccion": "7.2", "categoria": "Requisito 7: Restringir el acceso a los componentes del sistema y a los datos de tarjetahabiente según la necesidad de conocer del negocio", "categoria_en": "Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know", "seccion_titulo": "Acceso a componentes y datos definido y asignado adecuadamente", "seccion_titulo_en": "Access to system components and data is appropriately defined and assigned", "descripcion_corta": "Privilegios requeridos aprobados por personal autorizado", "descripcion_larga": "Todo privilegio otorgado debe contar con la aprobación del personal autorizado, documentada por escrito o electrónicamente. Así se asegura que quienes tienen acceso son conocidos y autorizados por la gerencia y que el acceso es necesario para su función. El evaluador compara los IDs de usuario y sus privilegios contra las aprobaciones para verificar que existe aprobación documentada, que la otorgó personal autorizado y que los privilegios coinciden con los roles asignados.", "remediacion": "1) Define en el procedimiento quién puede aprobar cada tipo de privilegio (p. ej., jefe directo y dueño del sistema o datos del CDE). 2) Canaliza toda alta o cambio de acceso a la nube por un sistema de tickets o de gobierno de identidades (ServiceNow, Jira, Entra ID Access Packages/Entitlement Management, AWS IAM Identity Center con aprovisionamiento SCIM desde el IdP) que registre solicitante, aprobador, fecha y rol. 3) Para privilegios elevados usa flujos con aprobación obligatoria: Entra ID PIM con aprobación, Google Cloud PAM con aprobadores, o soluciones de acceso temporal en AWS. 4) Bloquea cambios manuales de IAM fuera del flujo (restricción con SCP/Azure Policy y alertas de CloudTrail/Activity Log/Cloud Audit Logs sobre cambios de IAM). 5) Evidencia: muestra de usuarios con sus privilegios actuales y el ticket de aprobación correspondiente.", "descripcion_corta_en": "Required privileges approved by authorized personnel", "descripcion_larga_en": "Every privilege granted must be approved by authorized personnel, with the approval documented in writing or electronically. This ensures that people with access are known and authorized by management and that the access is needed for their job. The assessor compares user IDs and assigned privileges against approvals to confirm documented approval exists, was given by authorized personnel, and that the privileges match the assigned roles.", "remediacion_en": "1) Define in the procedure who may approve each privilege type (e.g., direct manager plus the CDE system or data owner). 2) Route every cloud access grant or change through a ticketing or identity governance system (ServiceNow, Jira, Entra ID Access Packages/Entitlement Management, AWS IAM Identity Center with SCIM provisioning from the IdP) recording requester, approver, date and role. 3) For elevated privileges use flows with mandatory approval: Entra ID PIM with approval, Google Cloud PAM with approvers, or temporary-access solutions in AWS. 4) Block manual IAM changes outside the flow (SCP/Azure Policy restrictions and CloudTrail/Activity Log/Cloud Audit Logs alerts on IAM changes). 5) Evidence: a sample of users with current privileges and the matching approval ticket.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 171, "pagina_pdf_es": 182 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Procedimiento de aprobación de accesos y registros de aprobación (tickets, PIM, Access Packages); Kyber puede aportar el listado actual de usuarios y privilegios para cotejarlo contra las aprobaciones.", "evidencia_en": "Access approval procedure and approval records (tickets, PIM, Access Packages); Kyber can supply the current list of users and privileges to reconcile against approvals.", "limitaciones": "El escaneo de configuración no ve las aprobaciones de negocio ni puede determinar si quien aprobó estaba autorizado.", "limitaciones_en": "Configuration scanning cannot see business approvals or determine whether the approver was authorized.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.18" ], "soc2_tsc": [ "CC6.2", "CC6.3" ], "cis_controls_v8": [ "6.1" ] } }, { "id": 98, "numero_regla": "7.2.4", "requisito": "7", "seccion": "7.2", "categoria": "Requisito 7: Restringir el acceso a los componentes del sistema y a los datos de tarjetahabiente según la necesidad de conocer del negocio", "categoria_en": "Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know", "seccion_titulo": "Acceso a componentes y datos definido y asignado adecuadamente", "seccion_titulo_en": "Access to system components and data is appropriately defined and assigned", "descripcion_corta": "Revisión semestral de cuentas de usuario y privilegios, incluidas las de terceros", "descripcion_larga": "Todas las cuentas de usuario y sus privilegios, incluidas las de terceros/proveedores, deben revisarse al menos una vez cada seis meses para confirmar que siguen siendo apropiados según la función laboral, atender cualquier acceso inadecuado y dejar constancia de que la gerencia reconoce que el acceso sigue siendo apropiado. Aplica a cuentas de personal y de terceros, así como a las cuentas usadas para acceder a servicios de nube de terceros; las cuentas de aplicación y sistema se cubren en 7.2.5, 7.2.5.1 y 8.6.1-8.6.3. La revisión también permite detectar cuentas de usuarios dados de baja que no se eliminaron. Fue práctica recomendada hasta el 31 de marzo de 2025 y desde entonces es obligatoria.", "remediacion": "1) Programa una campaña de revisión de accesos al menos cada 6 meses que cubra consolas y APIs de nube (AWS IAM e Identity Center, Azure Entra ID/RBAC, GCP IAM), incluyendo invitados B2B, usuarios federados y cuentas de proveedores. 2) Genera el listado de cuentas con su rol, alcance, último inicio de sesión y última actividad (AWS credential report e IAM Access Analyzer de accesos no usados; Entra ID sign-in activity; GCP Policy Intelligence/Activity Analyzer) y márcalo contra la nómina de personal y contratos vigentes. 3) Automatiza la campaña donde sea posible: Entra ID Access Reviews recurrentes para roles de Azure y grupos; revisión de permission sets en Identity Center. 4) Deshabilita credenciales sin uso por más de 90 días y retira de inmediato accesos de bajas o cambios de puesto. 5) Documenta las correcciones realizadas y obtén la firma de la gerencia que reconoce que los accesos restantes son apropiados. 6) Evidencia para el QSA: listados fechados de las dos últimas revisiones, decisiones por cuenta, tickets de corrección y aprobación de la gerencia.", "descripcion_corta_en": "Semi-annual review of user accounts and privileges, including third parties", "descripcion_larga_en": "All user accounts and their privileges, including third-party/vendor accounts, must be reviewed at least once every six months to confirm they remain appropriate for the job function, to address any inappropriate access, and to record management's acknowledgment that access remains appropriate. It applies to personnel and third-party accounts as well as accounts used to access third-party cloud services; application and system accounts are covered by 7.2.5, 7.2.5.1 and 8.6.1-8.6.3. The review also catches accounts of terminated users that were not removed. It was a best practice until 31 March 2025 and is mandatory thereafter.", "remediacion_en": "1) Schedule an access review campaign at least every 6 months covering cloud consoles and APIs (AWS IAM and Identity Center, Azure Entra ID/RBAC, GCP IAM), including B2B guests, federated users and vendor accounts. 2) Generate the account list with role, scope, last sign-in and last activity (AWS credential report and IAM Access Analyzer unused access; Entra ID sign-in activity; GCP Policy Intelligence/Activity Analyzer) and reconcile it against HR rosters and active contracts. 3) Automate the campaign where possible: recurring Entra ID Access Reviews for Azure roles and groups; Identity Center permission set reviews. 4) Disable credentials unused for more than 90 days and immediately remove access for leavers or role changes. 5) Document remediation and obtain management sign-off acknowledging remaining access is appropriate. 6) QSA evidence: dated lists from the last two reviews, per-account decisions, remediation tickets and management approval.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 172, "pagina_pdf_es": 183 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Credential report de IAM: usuarios con contraseña o llaves de acceso sin uso en más de 90 días (falla si existen) [IAM.8]", "IAM Access Analyzer de accesos no usados habilitado y hallazgos de usuarios/roles inactivos", "IAM Identity Center: usuarios y asignaciones de permission sets sin inicio de sesión en más de 90 días (falla si existen)", "Usuarios IAM locales (no federados) con acceso a consola en cuentas del CDE (alerta)" ], "checks_azure": [ "Entra ID: usuarios y huéspedes con lastSignInDateTime mayor a 90 días que conservan asignaciones RBAC (falla si existen)", "Entra ID Access Reviews configuradas con recurrencia de 6 meses o menor para roles privilegiados y grupos con acceso al CDE", "Usuarios invitados (B2B) con roles de Azure en suscripciones del CDE (alerta para revisión)" ], "checks_gcp": [ "Miembros user: en bindings de IAM sin actividad en más de 90 días según Policy Intelligence/Activity Analyzer (falla si existen)", "Bindings con cuentas de dominios externos a la organización (falla si existe; restringir con iam.allowedPolicyMemberDomains)", "Recomendaciones de IAM Recommender sin atender sobre permisos no usados" ], "evidencia": "Kyber genera el listado semestral de cuentas de usuario por nube con rol, alcance, último acceso y marca de inactividad mayor a 90 días, listo para que la gerencia lo revise y firme; el cliente aporta las decisiones, correcciones y el reconocimiento de la gerencia.", "evidencia_en": "Kyber generates the semi-annual per-cloud user account list with role, scope, last access and a flag for inactivity over 90 days, ready for management review and sign-off; the customer provides decisions, remediation and management acknowledgment.", "limitaciones": "Kyber no puede decidir si un acceso es apropiado para la función laboral ni sustituir el reconocimiento de la gerencia; tampoco ve cuentas de sistemas operativos, bases de datos o aplicaciones SaaS fuera de la nube escaneada.", "limitaciones_en": "Kyber cannot decide whether access is appropriate for the job function or replace management acknowledgment; it also does not see OS, database or SaaS application accounts outside the scanned cloud.", "responsabilidad_compartida": "cliente", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.18", "8.2" ], "soc2_tsc": [ "CC6.2", "CC6.3" ], "cis_controls_v8": [ "5.1", "5.3", "6.2" ], "banxico_spei": [ "58a. I.A.e).4", "59a. Bis" ] } }, { "id": 99, "numero_regla": "7.2.5", "requisito": "7", "seccion": "7.2", "categoria": "Requisito 7: Restringir el acceso a los componentes del sistema y a los datos de tarjetahabiente según la necesidad de conocer del negocio", "categoria_en": "Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know", "seccion_titulo": "Acceso a componentes y datos definido y asignado adecuadamente", "seccion_titulo_en": "Access to system components and data is appropriately defined and assigned", "descripcion_corta": "Cuentas de aplicación y de sistema con mínimo privilegio y uso limitado a donde se requieren", "descripcion_larga": "Todas las cuentas de aplicación y de sistema, y sus privilegios, deben asignarse y administrarse con los privilegios mínimos necesarios para que el sistema o la aplicación funcione, y su acceso debe limitarse a los sistemas, aplicaciones o procesos que específicamente las necesitan. Si una de estas cuentas se ve comprometida, el atacante obtiene el mismo nivel de acceso que ella, por lo que deben limitarse con el mismo rigor que las cuentas de usuario (p. ej., no pertenecer a grupos privilegiados como administradores de dominio o root, restringir desde dónde y en qué horario se usan y retirar accesos remotos innecesarios). Fue práctica recomendada hasta el 31 de marzo de 2025 y desde entonces es obligatoria.", "remediacion": "1) Inventaría las identidades no humanas del CDE: roles IAM de servicio y perfiles de instancia, roles de ejecución de Lambda/ECS (AWS); identidades administradas y service principals (Azure); service accounts de GCP y sus llaves. 2) AWS: una identidad por carga de trabajo; elimina AdministratorAccess y políticas \"*:*\" de roles de servicio; acota Resource a ARNs concretos; agrega condiciones (aws:SourceVpc, aws:SourceAccount) y políticas de confianza que solo permitan al servicio o cuenta esperados; usa Access Analyzer para recortar permisos no usados. 3) Azure: prefiere identidades administradas sobre service principals con secretos; asigna roles de datos específicos (p. ej., Storage Blob Data Reader) en el alcance del recurso, nunca Owner/Contributor de suscripción. 4) GCP: no uses la service account predeterminada de Compute Engine con el rol Editor; desactiva la concesión automática (iam.automaticIamGrantsForDefaultServiceAccounts); evita llaves de usuario (iam.disableServiceAccountKeyCreation) y usa Workload Identity; no otorgues roles de administrador a service accounts ni Service Account User/Token Creator a nivel proyecto. 5) Evidencia: inventario de cuentas de servicio con sus permisos y la justificación funcional de cada una.", "descripcion_corta_en": "Application and system accounts with least privilege and restricted to where they are needed", "descripcion_larga_en": "All application and system accounts and their privileges must be assigned and managed with the least privileges needed for the system or application to operate, and their access must be limited to the systems, applications or processes that specifically need them. If such an account is compromised, the attacker gains its access level, so these accounts must be restricted as rigorously as user accounts (e.g., not members of privileged groups such as domain admins or root, restricted in where and when they can be used, and stripped of unnecessary remote access). It was a best practice until 31 March 2025 and is mandatory thereafter.", "remediacion_en": "1) Inventory non-human identities in the CDE: service IAM roles and instance profiles, Lambda/ECS execution roles (AWS); managed identities and service principals (Azure); GCP service accounts and their keys. 2) AWS: one identity per workload; remove AdministratorAccess and \"*:*\" policies from service roles; scope Resource to specific ARNs; add conditions (aws:SourceVpc, aws:SourceAccount) and trust policies allowing only the expected service or account; use Access Analyzer to trim unused permissions. 3) Azure: prefer managed identities over service principals with secrets; assign specific data roles (e.g., Storage Blob Data Reader) at resource scope, never subscription Owner/Contributor. 4) GCP: do not use the Compute Engine default service account with the Editor role; disable automatic grants (iam.automaticIamGrantsForDefaultServiceAccounts); avoid user-managed keys (iam.disableServiceAccountKeyCreation) and use Workload Identity; do not grant admin roles to service accounts or Service Account User/Token Creator at project level. 5) Evidence: inventory of service accounts with their permissions and the functional justification for each.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 173, "pagina_pdf_es": 185 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Roles IAM de servicio, perfiles de instancia y roles de ejecución de Lambda/ECS con AdministratorAccess o políticas Action \"*\" / Resource \"*\" (falla si existe) [IAM.1]", "Políticas de confianza de roles que permiten Principal \"*\" o cuentas externas sin condición sts:ExternalId (falla si existe)", "Roles de servicio sin uso en más de 90 días según último acceso (falla si existen)", "Usuarios IAM usados por aplicaciones con llaves de acceso de más de 90 días sin rotar (falla si existe) [IAM.3]" ], "checks_azure": [ "Service principals o identidades administradas con Owner, Contributor o User Access Administrator en alcance de suscripción o grupo de administración (falla si existe)", "Service principals con secretos de cliente sin fecha de expiración o con vigencia mayor a 1 año (falla si existe)", "Máquinas virtuales y App Services del CDE sin identidad administrada que usan credenciales embebidas (alerta)" ], "checks_gcp": [ "Service accounts con roles de administrador, roles/owner o roles/editor (falla si existe) [CIS GCP 1.5]", "Instancias de Compute Engine que usan la service account predeterminada con alcance cloud-platform (falla si existe)", "Llaves de service account administradas por el usuario existentes o con más de 90 días (falla si existe) [CIS GCP 1.4, 1.7]", "Usuarios con roles/iam.serviceAccountUser o roles/iam.serviceAccountTokenCreator a nivel proyecto (falla si existe) [CIS GCP 1.6]" ], "evidencia": "Kyber genera el inventario de identidades no humanas (roles de servicio, service principals, identidades administradas, service accounts y sus llaves) con permisos efectivos y hallazgos de exceso; el cliente aporta la justificación funcional de cada cuenta.", "evidencia_en": "Kyber generates the inventory of non-human identities (service roles, service principals, managed identities, service accounts and their keys) with effective permissions and excess-privilege findings; the customer provides the functional justification for each account.", "limitaciones": "El escaneo no puede determinar cuál es el mínimo privilegio necesario para que cada aplicación opere ni cubre cuentas de sistema dentro de sistemas operativos, bases de datos o aplicaciones.", "limitaciones_en": "Scanning cannot determine the minimum privilege each application needs to operate, nor does it cover system accounts inside operating systems, databases or applications.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.15", "5.18", "8.2" ], "soc2_tsc": [ "CC6.1", "CC6.3" ], "cis_controls_v8": [ "5.5", "6.8" ] } }, { "id": 100, "numero_regla": "7.2.5.1", "requisito": "7", "seccion": "7.2", "categoria": "Requisito 7: Restringir el acceso a los componentes del sistema y a los datos de tarjetahabiente según la necesidad de conocer del negocio", "categoria_en": "Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know", "seccion_titulo": "Acceso a componentes y datos definido y asignado adecuadamente", "seccion_titulo_en": "Access to system components and data is appropriately defined and assigned", "descripcion_corta": "Revisión periódica, según análisis de riesgos, del acceso de cuentas de aplicación y sistema", "descripcion_larga": "Todo el acceso de las cuentas de aplicación y de sistema y sus privilegios debe revisarse periódicamente, con la frecuencia que determine el análisis de riesgos específico de la entidad realizado conforme al Requisito 12.3.1. La revisión confirma que el acceso sigue siendo apropiado para la función que realiza la aplicación o sistema, atiende cualquier acceso inadecuado y deja constancia de que la gerencia reconoce que el acceso sigue siendo apropiado. Fue práctica recomendada hasta el 31 de marzo de 2025 y desde entonces es obligatoria.", "remediacion": "1) Realiza y documenta el análisis de riesgos específico (Requisito 12.3.1) que fije la frecuencia de revisión de cuentas de servicio; una referencia común es trimestral o semestral, y más frecuente para identidades con acceso a datos de tarjeta. 2) En cada ciclo genera el listado de roles de servicio, service principals, identidades administradas y service accounts de GCP con sus permisos, llaves/secretos y última actividad (IAM last accessed y Access Analyzer; Entra ID sign-in logs de service principals; Policy Intelligence/Activity Analyzer y Recommender en GCP). 3) Reduce permisos no usados, elimina identidades y llaves inactivas por más de 90 días y rota secretos vencidos. 4) Registra las decisiones y correcciones en tickets y obtén el reconocimiento formal de la gerencia. 5) Evidencia: análisis de riesgos con la frecuencia, listados fechados de cada revisión, tickets de corrección y firma de la gerencia.", "descripcion_corta_en": "Periodic, risk-based review of application and system account access", "descripcion_larga_en": "All access by application and system accounts and their privileges must be reviewed periodically, at the frequency set by the entity's targeted risk analysis performed per Requirement 12.3.1. The review confirms access remains appropriate for the function the application or system performs, addresses any inappropriate access, and records management's acknowledgment that access remains appropriate. It was a best practice until 31 March 2025 and is mandatory thereafter.", "remediacion_en": "1) Perform and document the targeted risk analysis (Requirement 12.3.1) that sets the review frequency for service accounts; quarterly or semi-annual is common, more often for identities with access to cardholder data. 2) Each cycle, generate the list of service roles, service principals, managed identities and GCP service accounts with permissions, keys/secrets and last activity (IAM last accessed and Access Analyzer; Entra ID service principal sign-in logs; GCP Policy Intelligence/Activity Analyzer and Recommender). 3) Trim unused permissions, remove identities and keys inactive for over 90 days and rotate expired secrets. 4) Record decisions and fixes in tickets and obtain formal management acknowledgment. 5) Evidence: risk analysis with the frequency, dated lists from each review, remediation tickets and management sign-off.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 174, "pagina_pdf_es": 186 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Roles IAM de servicio sin uso en más de 90 días según RoleLastUsed (falla si existen)", "IAM Access Analyzer de accesos no usados: permisos, roles y llaves de acceso no usados (falla si existen hallazgos activos)", "Llaves de acceso de usuarios técnicos sin uso o sin rotar en más de 90 días (falla si existe) [IAM.3]" ], "checks_azure": [ "Service principals y aplicaciones registradas sin inicio de sesión en más de 90 días que conservan roles RBAC (falla si existen)", "Secretos y certificados de service principals vencidos o próximos a vencer (alerta)", "Entra ID Access Reviews o revisión equivalente configurada para service principals con roles privilegiados" ], "checks_gcp": [ "Service accounts sin autenticación en más de 90 días según Activity Analyzer (falla si existen)", "Llaves de service account administradas por el usuario sin uso o con más de 90 días (falla si existe) [CIS GCP 1.7]", "Recomendaciones de IAM Recommender sobre service accounts con permisos en exceso sin atender (falla si existen)" ], "evidencia": "Kyber genera el listado periódico de cuentas de aplicación/sistema por nube con permisos, llaves/secretos y última actividad, marcando inactividad mayor a 90 días; el cliente aporta el análisis de riesgos que define la frecuencia, las decisiones y el reconocimiento de la gerencia.", "evidencia_en": "Kyber generates the periodic per-cloud list of application/system accounts with permissions, keys/secrets and last activity, flagging inactivity over 90 days; the customer provides the targeted risk analysis defining frequency, the decisions and management acknowledgment.", "limitaciones": "Kyber no puede validar el análisis de riesgos, decidir si el acceso es apropiado para la función ni sustituir el reconocimiento de la gerencia; no ve cuentas de sistema dentro de SO, bases de datos o aplicaciones.", "limitaciones_en": "Kyber cannot validate the risk analysis, decide whether access is appropriate for the function or replace management acknowledgment; it does not see system accounts inside OSs, databases or applications.", "responsabilidad_compartida": "cliente", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.18", "8.2" ], "soc2_tsc": [ "CC6.2", "CC6.3" ], "cis_controls_v8": [ "5.5", "5.3" ] } }, { "id": 101, "numero_regla": "7.2.6", "requisito": "7", "seccion": "7.2", "categoria": "Requisito 7: Restringir el acceso a los componentes del sistema y a los datos de tarjetahabiente según la necesidad de conocer del negocio", "categoria_en": "Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know", "seccion_titulo": "Acceso a componentes y datos definido y asignado adecuadamente", "seccion_titulo_en": "Access to system components and data is appropriately defined and assigned", "descripcion_corta": "Consultas a repositorios de CHD solo vía aplicaciones; acceso directo solo para administradores", "descripcion_larga": "Todo acceso de usuarios para consultar repositorios de datos de titulares de tarjeta almacenados debe restringirse de modo que se realice mediante aplicaciones u otros métodos programáticos (p. ej., procedimientos almacenados), con acceso y acciones permitidas según el rol del usuario y el mínimo privilegio, y que solo los administradores responsables puedan acceder o consultar directamente dichos repositorios. Se prohíbe la consulta directa y sin filtro (ad hoc) por parte de usuarios finales, ya que el mal uso de este acceso ha sido causa frecuente de filtraciones. Aplica a los controles del acceso de usuarios; las cuentas de aplicación y sistema se cubren en 7.2.5, 7.2.5.1 y 8.6.1-8.6.3.", "remediacion": "1) Identifica todos los repositorios con datos de tarjeta (RDS/Aurora, DynamoDB, Redshift, S3; Azure SQL, Cosmos DB, Storage; Cloud SQL, BigQuery, Cloud Storage, Spanner). 2) Restringe la red: bases de datos sin acceso público y solo alcanzables desde la capa de aplicación o bastión administrativo. 3) Autenticación centralizada: IAM database authentication en RDS/Aurora, autenticación de Entra ID en Azure SQL/PostgreSQL/MySQL con administrador de Entra ID definido, IAM database authentication en Cloud SQL; elimina cuentas de base de datos compartidas. 4) Concede rds-db:connect, roles de datos (Storage Blob Data Reader, roles/bigquery.dataViewer, s3:GetObject) solo a roles de aplicación y al grupo de DBA autorizado; usuarios de negocio acceden por la aplicación o por vistas/procedimientos almacenados con columnas enmascaradas (BigQuery column-level security/data masking, Azure SQL Dynamic Data Masking). 5) Políticas de bucket que denieguen acceso a todo principal distinto de los roles de aplicación y administradores. 6) Evidencia: lista de principales con acceso directo a cada repositorio, justificación de administrador y configuración de autenticación/red.", "descripcion_corta_en": "Queries to CHD repositories only via applications; direct access for administrators only", "descripcion_larga_en": "All user access to query repositories of stored cardholder data must be restricted so that it occurs through applications or other programmatic methods (e.g., stored procedures), with access and allowed actions based on user roles and least privilege, and only the responsible administrator(s) may directly access or query those repositories. Direct, unfiltered (ad hoc) query access by end users is prohibited, as misuse of such access is a frequent cause of breaches. It applies to user access controls; application and system accounts are covered by 7.2.5, 7.2.5.1 and 8.6.1-8.6.3.", "remediacion_en": "1) Identify every repository holding cardholder data (RDS/Aurora, DynamoDB, Redshift, S3; Azure SQL, Cosmos DB, Storage; Cloud SQL, BigQuery, Cloud Storage, Spanner). 2) Restrict the network: no public database access, reachable only from the application tier or an administrative bastion. 3) Centralize authentication: IAM database authentication on RDS/Aurora, Entra ID authentication on Azure SQL/PostgreSQL/MySQL with an Entra ID admin set, IAM database authentication on Cloud SQL; remove shared database accounts. 4) Grant rds-db:connect and data roles (Storage Blob Data Reader, roles/bigquery.dataViewer, s3:GetObject) only to application roles and the authorized DBA group; business users access data through the application or via views/stored procedures with masked columns (BigQuery column-level security/data masking, Azure SQL Dynamic Data Masking). 5) Use bucket policies that deny access to any principal other than application roles and administrators. 6) Evidence: list of principals with direct access to each repository, administrator justification, and authentication/network configuration.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 175, "pagina_pdf_es": 187 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "RDS/Aurora con PubliclyAccessible = true (falla si existe) [RDS.2]", "RDS/Aurora sin IAM database authentication habilitada (falla) [RDS.10]", "Principales IAM con rds-db:connect, dynamodb:* o s3:GetObject sobre recursos del CDE que no sean roles de aplicación ni el grupo de DBA autorizado (falla si existe)", "Buckets S3 con datos del CDE sin Block Public Access o con política de bucket que permite Principal \"*\" (falla si existe) [S3.8]", "Redshift con PubliclyAccessible = true (falla si existe)" ], "checks_azure": [ "Azure SQL / PostgreSQL / MySQL sin administrador de Entra ID configurado o con autenticación solo SQL (falla)", "Azure SQL con publicNetworkAccess = Enabled y reglas de firewall 0.0.0.0-255.255.255.255 (falla si existe)", "Asignaciones de roles de datos (Storage Blob Data Reader/Contributor, Cosmos DB Data Contributor) a usuarios individuales sobre recursos del CDE (falla si existe)", "Storage Accounts del CDE con allowBlobPublicAccess = true (falla)" ], "checks_gcp": [ "Cloud SQL con IP pública y authorizedNetworks 0.0.0.0/0 (falla si existe)", "Cloud SQL sin la marca cloudsql.iam_authentication habilitada (falla)", "Datasets de BigQuery y buckets del CDE con bindings a allUsers o allAuthenticatedUsers (falla si existe)", "Bindings de roles/bigquery.dataViewer, roles/cloudsql.client o roles/storage.objectViewer a usuarios individuales sobre recursos del CDE (falla si existe)" ], "evidencia": "Kyber genera, por repositorio de CHD, el listado de principales con acceso directo y la configuración de red y autenticación; el cliente aporta la designación de administradores responsables y evidencia de que los usuarios consultan mediante la aplicación.", "evidencia_en": "Kyber generates, per CHD repository, the list of principals with direct access plus network and authentication configuration; the customer provides the designation of responsible administrators and evidence that users query via the application.", "limitaciones": "El escaneo agentless no ve usuarios, grants ni procedimientos almacenados internos del motor de base de datos, ni puede determinar qué repositorios contienen CHD sin el inventario de datos del cliente.", "limitaciones_en": "Agentless scanning does not see users, grants or stored procedures inside the database engine, nor can it tell which repositories contain CHD without the customer's data inventory.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.3", "8.2", "5.15" ], "soc2_tsc": [ "CC6.1", "CC6.3" ], "cis_controls_v8": [ "3.3", "6.8" ] } }, { "id": 102, "numero_regla": "7.3.1", "requisito": "7", "seccion": "7.3", "categoria": "Requisito 7: Restringir el acceso a los componentes del sistema y a los datos de tarjetahabiente según la necesidad de conocer del negocio", "categoria_en": "Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know", "seccion_titulo": "Acceso gestionado mediante sistemas de control de acceso", "seccion_titulo_en": "Access is managed via an access control system(s)", "descripcion_corta": "Sistema de control de acceso que restringe por necesidad de conocer en todos los componentes", "descripcion_larga": "Debe existir uno o más sistemas de control de acceso que restrinjan el acceso según la necesidad de conocer de cada usuario y que abarquen todos los componentes del sistema. Estos mecanismos automatizan la restricción del acceso y la asignación de privilegios, evitando que un usuario obtenga acceso a datos de tarjeta sin necesitarlo. El evaluador revisa la documentación del proveedor y la configuración para confirmar que cada componente está gobernado por dicho sistema.", "remediacion": "1) Centraliza la identidad: AWS IAM Identity Center federado con el IdP corporativo para todas las cuentas de AWS Organizations; Entra ID como único directorio para suscripciones de Azure; Cloud Identity/Google Workspace o federación para la organización de GCP. 2) Extiende el control a los componentes dentro de la nube: SSM Session Manager, Entra ID login para VMs o OS Login en GCP en lugar de llaves SSH locales; autenticación IAM/Entra ID en bases de datos; RBAC de Kubernetes integrado con IAM (EKS access entries, AKS con Entra ID y Azure RBAC, GKE con IAM/Google Groups for RBAC). 3) Elimina mecanismos paralelos sin control centralizado (usuarios IAM locales, cuentas locales de VM, llaves SSH en metadatos de proyecto). 4) Evidencia: diagrama/inventario de componentes del CDE y el sistema de control de acceso que gobierna cada uno, con la configuración exportada.", "descripcion_corta_en": "Access control system restricting by need to know across all components", "descripcion_larga_en": "One or more access control systems must be in place that restrict access according to each user's need to know and cover all system components. These mechanisms automate restricting access and assigning privileges, preventing users from obtaining cardholder data access they do not need. The assessor reviews vendor documentation and settings to confirm each component is governed by such a system.", "remediacion_en": "1) Centralize identity: AWS IAM Identity Center federated with the corporate IdP for all AWS Organizations accounts; Entra ID as the sole directory for Azure subscriptions; Cloud Identity/Google Workspace or federation for the GCP organization. 2) Extend control to components within the cloud: SSM Session Manager, Entra ID login for VMs or GCP OS Login instead of local SSH keys; IAM/Entra ID authentication for databases; Kubernetes RBAC integrated with IAM (EKS access entries, AKS with Entra ID and Azure RBAC, GKE with IAM/Google Groups for RBAC). 3) Remove parallel mechanisms lacking central control (local IAM users, local VM accounts, project-wide SSH keys in metadata). 4) Evidence: CDE component inventory/diagram and the access control system governing each, with exported configuration.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 176, "pagina_pdf_es": 188 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "IAM Identity Center habilitado y federado con IdP externo para las cuentas del CDE", "Usuarios IAM locales con contraseña de consola en cuentas del CDE (falla si existen fuera de excepciones documentadas)", "Instancias EC2 del CDE gestionadas por SSM Session Manager sin pares de llaves SSH asignados (alerta si usan key pairs)", "Clústeres EKS con modo de autenticación API (access entries) en lugar de solo aws-auth ConfigMap (alerta)" ], "checks_azure": [ "Suscripciones del CDE asociadas al tenant de Entra ID corporativo", "AKS con integración de Entra ID y Azure RBAC habilitados y cuentas locales deshabilitadas (disableLocalAccounts = true)", "VMs Linux del CDE con autenticación por contraseña habilitada en lugar de Entra ID login o llaves administradas (falla)" ], "checks_gcp": [ "Metadato de proyecto enable-oslogin = TRUE en proyectos del CDE (falla si falta)", "Instancias sin block-project-ssh-keys = true (falla)", "GKE con autenticación básica o certificados de cliente heredados habilitados (falla si existe)" ], "evidencia": "Kyber genera el inventario de componentes del CDE por nube indicando el mecanismo de control de acceso que los gobierna; el cliente aporta documentación del IdP y de los controles de acceso de aplicaciones y sistemas fuera del plano de control de la nube.", "evidencia_en": "Kyber generates the per-cloud CDE component inventory showing the access control mechanism governing each; the customer provides IdP documentation and access controls for applications and systems outside the cloud control plane.", "limitaciones": "El escaneo no confirma que las reglas reflejen la necesidad de conocer de cada usuario ni cubre controles de acceso dentro de aplicaciones, bases de datos o sistemas on-premises.", "limitaciones_en": "Scanning does not confirm that rules reflect each user's need to know, nor does it cover access controls inside applications, databases or on-premises systems.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.15", "8.3", "5.16" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "6.7", "3.3" ] } }, { "id": 103, "numero_regla": "7.3.2", "requisito": "7", "seccion": "7.3", "categoria": "Requisito 7: Restringir el acceso a los componentes del sistema y a los datos de tarjetahabiente según la necesidad de conocer del negocio", "categoria_en": "Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know", "seccion_titulo": "Acceso gestionado mediante sistemas de control de acceso", "seccion_titulo_en": "Access is managed via an access control system(s)", "descripcion_corta": "Sistema de control de acceso aplica permisos a personas, aplicaciones y sistemas por función", "descripcion_larga": "Los sistemas de control de acceso deben configurarse para hacer cumplir los permisos asignados a individuos, aplicaciones y sistemas con base en la clasificación y función del puesto. Restringir el acceso privilegiado mediante el sistema de control de acceso reduce errores al asignar permisos. El objetivo es que los derechos y privilegios de cada cuenta se hereden únicamente de su pertenencia a grupos o roles, no de asignaciones individuales.", "remediacion": "1) Asigna permisos solo a grupos o roles que representen funciones laborales, nunca directamente a usuarios: AWS IAM Identity Center permission sets asignados a grupos del IdP y sin políticas adjuntas a usuarios IAM; Azure RBAC asignado a grupos de Entra ID; GCP bindings a Google Groups. 2) Para cargas de trabajo usa roles de servicio/identidades administradas/service accounts dedicadas por función. 3) Aprovisiona la membresía de grupos desde el IdP vía SCIM para que altas, cambios y bajas se reflejen automáticamente. 4) Aplica guardrails: SCP o Azure Policy/Organization Policy que impidan adjuntar políticas a usuarios o asignar roles a cuentas individuales. 5) Evidencia: exportación de asignaciones mostrando que los permisos provienen de grupos/roles y la correspondencia grupo-función.", "descripcion_corta_en": "Access control system enforces permissions for individuals, applications and systems by job function", "descripcion_larga_en": "Access control systems must be configured to enforce the permissions assigned to individuals, applications and systems based on job classification and function. Restricting privileged access through the access control system reduces errors in permission assignment. The goal is that each account's rights and privileges are inherited only through group or role membership, not individual grants.", "remediacion_en": "1) Assign permissions only to groups or roles representing job functions, never directly to users: AWS IAM Identity Center permission sets assigned to IdP groups and no policies attached to IAM users; Azure RBAC assigned to Entra ID groups; GCP bindings to Google Groups. 2) For workloads use dedicated service roles/managed identities/service accounts per function. 3) Provision group membership from the IdP via SCIM so joiners, movers and leavers are reflected automatically. 4) Apply guardrails: SCPs or Azure Policy/Organization Policy preventing policy attachment to users or role assignment to individual accounts. 5) Evidence: assignment export showing permissions come from groups/roles and the group-to-function mapping.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 176, "pagina_pdf_es": 188 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Usuarios IAM con políticas administradas o en línea adjuntas directamente (falla si existe) [IAM.2]", "Asignaciones de permission sets de IAM Identity Center hechas a usuarios individuales en lugar de grupos (falla si existe)", "Roles de servicio compartidos por múltiples cargas de trabajo con funciones distintas (alerta)" ], "checks_azure": [ "Asignaciones RBAC con principalType = User sobre suscripciones, grupos de recursos o recursos del CDE (falla si existe, salvo excepciones documentadas)", "Roles de directorio de Entra ID asignados directamente a usuarios en lugar de grupos con asignación de roles habilitada (alerta)" ], "checks_gcp": [ "Bindings de IAM con miembros user: en organización, carpetas o proyectos del CDE (falla si existe; deben ser group:)", "Service accounts compartidas entre múltiples aplicaciones o instancias de funciones distintas (alerta)" ], "evidencia": "Kyber genera el reporte de asignaciones directas a usuarios versus asignaciones por grupo/rol en cada nube; el cliente aporta la correspondencia grupo-función laboral.", "evidencia_en": "Kyber generates the report of direct user assignments versus group/role assignments in each cloud; the customer provides the group-to-job-function mapping.", "limitaciones": "El escaneo verifica la estructura de asignación, pero no si la membresía de cada grupo corresponde a la función real del usuario.", "limitaciones_en": "Scanning verifies assignment structure, but not whether each group's membership matches the user's actual job function.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.15", "5.18", "8.2" ], "soc2_tsc": [ "CC6.1", "CC6.3" ], "cis_controls_v8": [ "6.8" ] } }, { "id": 104, "numero_regla": "7.3.3", "requisito": "7", "seccion": "7.3", "categoria": "Requisito 7: Restringir el acceso a los componentes del sistema y a los datos de tarjetahabiente según la necesidad de conocer del negocio", "categoria_en": "Requirement 7: Restrict Access to System Components and Cardholder Data by Business Need to Know", "seccion_titulo": "Acceso gestionado mediante sistemas de control de acceso", "seccion_titulo_en": "Access is managed via an access control system(s)", "descripcion_corta": "Sistema de control de acceso configurado en \"denegar todo\" por defecto", "descripcion_larga": "Los sistemas de control de acceso deben estar configurados para \"denegar todo\" de forma predeterminada, de modo que nadie obtenga acceso a menos que una regla lo conceda expresamente. Es importante revisar la configuración por defecto, ya que algunos sistemas vienen configurados para \"permitir todo\" hasta que se escribe una regla que lo impida.", "remediacion": "1) Mantén el modelo de denegación implícita de IAM en AWS, Azure RBAC y GCP IAM, evitando reglas que lo neutralicen: políticas de recursos (buckets S3, colas SQS, temas SNS, llaves KMS, funciones Lambda) con Principal \"*\" sin condiciones; Storage Accounts con acceso público a blobs; bindings a allUsers/allAuthenticatedUsers. 2) Activa S3 Block Public Access a nivel cuenta; en Azure establece allowBlobPublicAccess = false y publicNetworkAccess = Disabled donde aplique; en GCP aplica las Organization Policies storage.publicAccessPrevention e iam.allowedPolicyMemberDomains. 3) Usa SCP con denegaciones explícitas y Azure Policy en modo Deny para impedir configuraciones permisivas. 4) Revisa los valores predeterminados de otros sistemas de control de acceso (Kubernetes RBAC, bases de datos, aplicaciones) para que no permitan acceso por defecto. 5) Habilita IAM Access Analyzer de acceso externo (AWS) y revisa sus hallazgos. 6) Evidencia: configuración de bloqueo de acceso público, políticas organizacionales y resultados sin hallazgos de acceso público.", "descripcion_corta_en": "Access control system set to \"deny all\" by default", "descripcion_larga_en": "Access control systems must be set to \"deny all\" by default, so no one gains access unless a rule expressly grants it. It is important to check default settings, since some systems ship configured to \"allow all\" until a rule is written to block access.", "remediacion_en": "1) Preserve the implicit-deny model of AWS IAM, Azure RBAC and GCP IAM by avoiding rules that defeat it: resource policies (S3 buckets, SQS queues, SNS topics, KMS keys, Lambda functions) with Principal \"*\" and no conditions; Storage Accounts allowing public blob access; bindings to allUsers/allAuthenticatedUsers. 2) Enable account-level S3 Block Public Access; in Azure set allowBlobPublicAccess = false and publicNetworkAccess = Disabled where applicable; in GCP enforce the storage.publicAccessPrevention and iam.allowedPolicyMemberDomains Organization Policies. 3) Use SCPs with explicit denies and Azure Policy in Deny mode to block permissive configurations. 4) Review defaults of other access control systems (Kubernetes RBAC, databases, applications) so they do not allow access by default. 5) Enable IAM Access Analyzer external access (AWS) and review its findings. 6) Evidence: public-access-block configuration, organization policies and results with no public-access findings.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 177, "pagina_pdf_es": 189 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "S3 Block Public Access habilitado a nivel cuenta (falla si no) [S3.1]", "Políticas de bucket, SQS, SNS, KMS o Lambda con Principal \"*\" sin condiciones restrictivas (falla si existe) [Lambda.1]", "IAM Access Analyzer de acceso externo habilitado en todas las regiones y sin hallazgos activos de acceso público (falla si existen)", "Snapshots de EBS/RDS o AMIs compartidos públicamente (falla si existe) [RDS.1]" ], "checks_azure": [ "Storage Accounts con allowBlobPublicAccess = true o contenedores con nivel de acceso público (falla si existe)", "Azure Policy con efecto Deny asignada para impedir acceso público a almacenamiento y bases de datos en suscripciones del CDE", "Key Vaults del CDE sin modelo de permisos RBAC o con firewall que permite todas las redes (alerta)" ], "checks_gcp": [ "Bindings de IAM a allUsers o allAuthenticatedUsers en proyectos, buckets, datasets o funciones (falla si existe)", "Organization Policy storage.publicAccessPrevention aplicada (falla si no)", "Organization Policy iam.allowedPolicyMemberDomains restringida a los dominios de la organización (falla si no)" ], "evidencia": "Kyber genera el reporte de recursos con acceso público o anónimo y el estado de los bloqueos preventivos por nube; el cliente aporta evidencia de la configuración predeterminada de sistemas de control de acceso fuera del plano de control (aplicaciones, bases de datos).", "evidencia_en": "Kyber generates the report of resources with public or anonymous access and the status of preventive blocks per cloud; the customer provides evidence of default settings for access control systems outside the control plane (applications, databases).", "limitaciones": "La denegación implícita de IAM en las tres nubes es inherente al proveedor; el escaneo no verifica el valor predeterminado de controles de acceso dentro de aplicaciones o bases de datos.", "limitaciones_en": "Implicit deny in IAM across the three clouds is inherent to the provider; scanning does not verify defaults of access controls inside applications or databases.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.15", "8.3" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "3.3", "6.8" ] } }, { "id": 105, "numero_regla": "8.1.1", "requisito": "8", "seccion": "8.1", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Procesos y mecanismos de identificación y autenticación definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for identification and authentication are defined and understood", "descripcion_corta": "Políticas y procedimientos del Requisito 8 documentados, vigentes, en uso y comunicados", "descripcion_larga": "Las políticas de seguridad y los procedimientos operativos que exige el Requisito 8 (identificación de usuarios y autenticación) deben estar por escrito, mantenerse actualizados, aplicarse en la práctica y ser conocidos por todas las partes involucradas. El objetivo es que las expectativas, controles y supervisión de estas actividades estén definidos y que el personal los siga de forma repetible y conforme a la intención de la gerencia. Se recomienda actualizar los documentos en cuanto ocurra un cambio de proceso, tecnología u objetivo de negocio, y no solo en el ciclo periódico.", "remediacion": "1) Redacta una política de identificación de usuarios y autenticación y sus procedimientos operativos, incluyendo cómo se aplican en las cuentas y organizaciones de nube (AWS Organizations/IAM Identity Center, Azure Entra ID/RBAC, GCP Cloud Identity/IAM). 2) Asigna un dueño del documento, control de versiones y fecha de revisión al menos anual y tras cada cambio relevante. 3) Publica los documentos en un repositorio accesible y registra el acuse de lectura del personal afectado (administradores de nube, DevOps, seguridad, terceros). 4) Verifica que los procedimientos reflejen la operación real (por ejemplo, que el flujo de alta de accesos descrito coincida con el que se usa). 5) Conserva como evidencia para el QSA: documento aprobado con historial de versiones, constancias de difusión/acuse y entrevistas que confirmen su uso.", "descripcion_corta_en": "Requirement 8 policies and procedures documented, current, in use and communicated", "descripcion_larga_en": "The security policies and operational procedures required by Requirement 8 (user identification and authentication) must be written down, kept current, actually followed, and known to every affected party. The intent is that expectations, controls and oversight for these activities are defined and that staff carry them out repeatably and in line with management's intent. Documents should be updated as soon as processes, technologies or business objectives change, not only on a periodic cycle.", "remediacion_en": "1) Write a user identification and authentication policy and supporting operational procedures, including how they apply to cloud accounts and organizations (AWS Organizations/IAM Identity Center, Azure Entra ID/RBAC, GCP Cloud Identity/IAM). 2) Assign a document owner, version control and a review date at least annually and after any significant change. 3) Publish the documents in an accessible repository and record read acknowledgments from affected staff (cloud administrators, DevOps, security, third parties). 4) Confirm procedures match real operations (e.g., the documented access-request flow is the one actually used). 5) Keep as QSA evidence: approved document with version history, dissemination/acknowledgment records and interviews confirming use.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 180, "pagina_pdf_es": 192 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Política y procedimientos del Requisito 8 aprobados y versionados (Kyber puede generar la plantilla con el generador de políticas), registros de difusión y acuse de lectura del personal.", "evidencia_en": "Approved, versioned Requirement 8 policy and procedures (Kyber's policy generator can produce the template), plus dissemination and read-acknowledgment records.", "limitaciones": "El escaneo de nube no puede comprobar que las políticas estén vigentes, en uso ni que el personal las conozca.", "limitaciones_en": "Cloud scanning cannot confirm that policies are current, in use or known to staff.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.1", "5.37", "5.16", "5.17" ], "soc2_tsc": [ "CC1.3", "CC2.2", "CC5.3" ], "cis_controls_v8": [ "5.1", "6.3" ] } }, { "id": 106, "numero_regla": "8.1.2", "requisito": "8", "seccion": "8.1", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Procesos y mecanismos de identificación y autenticación definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for identification and authentication are defined and understood", "descripcion_corta": "Roles y responsabilidades del Requisito 8 documentados, asignados y comprendidos", "descripcion_larga": "Las funciones y responsabilidades para ejecutar las actividades del Requisito 8 (identificación de usuarios y autenticación) deben estar documentadas, asignadas a personas concretas y ser entendidas por ellas. Se busca que las tareas cotidianas estén repartidas y que el personal rinda cuentas de la operación continua y exitosa de estos controles. Pueden documentarse dentro de las políticas o en documentos aparte, por ejemplo con una matriz RACI y con el acuse de aceptación de cada responsable.", "remediacion": "1) Elabora una matriz RACI para las actividades del Requisito 8 (identificación de usuarios y autenticación) en la nube: quién solicita, aprueba, otorga, revisa y revoca accesos en AWS IAM/Identity Center, Azure Entra ID/RBAC y GCP IAM. 2) Asigna nombres o puestos concretos, incluidos suplentes y terceros (por ejemplo, el proveedor de servicios administrados). 3) Obtén el acuse firmado o electrónico de cada responsable y repítelo cuando cambien funciones o personal. 4) Revisa la matriz al menos una vez al año y tras reorganizaciones. 5) Evidencia para el QSA: matriz RACI aprobada, descripciones de puesto y acuses, más entrevistas en las que el personal describa sus responsabilidades.", "descripcion_corta_en": "Requirement 8 roles and responsibilities documented, assigned and understood", "descripcion_larga_en": "Roles and responsibilities for carrying out the activities in Requirement 8 (user identification and authentication) must be documented, assigned to specific people, and understood by them. The aim is that day-to-day duties are allocated and staff are accountable for the continuous, successful operation of these controls. They may be documented within policies or in separate documents, for example a RACI matrix with each owner's acknowledgment.", "remediacion_en": "1) Build a RACI matrix for Requirement 8 activities (user identification and authentication) in the cloud: who requests, approves, grants, reviews and revokes access in AWS IAM/Identity Center, Azure Entra ID/RBAC and GCP IAM. 2) Assign named people or positions, including backups and third parties (e.g., a managed service provider). 3) Collect signed or electronic acknowledgment from each owner and repeat it when roles or staff change. 4) Review the matrix at least annually and after reorganizations. 5) QSA evidence: approved RACI matrix, job descriptions and acknowledgments, plus interviews in which staff describe their responsibilities.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 181, "pagina_pdf_es": 193 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Matriz RACI o documento de roles del Requisito 8 aprobado, con acuses de los responsables.", "evidencia_en": "Approved RACI matrix or roles document for Requirement 8, with owners' acknowledgments.", "limitaciones": "El escaneo no puede verificar que los roles estén asignados ni que el personal los comprenda.", "limitaciones_en": "Scanning cannot verify that roles are assigned or understood by staff.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.2", "5.16", "5.17" ], "soc2_tsc": [ "CC1.3", "CC5.3" ], "cis_controls_v8": [ "5.1" ] } }, { "id": 107, "numero_regla": "8.2.1", "requisito": "8", "seccion": "8.2", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Identificación de usuarios y ciclo de vida de cuentas gestionados estrictamente", "seccion_titulo_en": "User identification and account lifecycle are strictly managed", "descripcion_corta": "ID único asignado a cada usuario antes de acceder a componentes del sistema o datos de tarjetahabiente", "descripcion_larga": "Cada usuario debe contar con un identificador propio e individual antes de que se le permita acceder a cualquier componente del sistema o a los datos del titular de la tarjeta. El objetivo es que toda acción realizada en el entorno pueda atribuirse a una persona concreta, lo que se comprueba revisando bitácoras de auditoría y otra evidencia. No aplica a cuentas de usuario de terminales de punto de venta que solo acceden a un número de tarjeta a la vez para procesar una única transacción.", "remediacion": "1) Centralice la identidad en un proveedor de identidad (AWS IAM Identity Center federado, Microsoft Entra ID, Google Workspace/Cloud Identity) y asigne una cuenta nominal por persona; evite usuarios IAM locales y cuentas genéricas. 2) No use la cuenta root de AWS para operación diaria: elimine sus llaves de acceso, habilite MFA y configure una alarma ante cualquier uso. 3) En Azure y GCP, otorgue roles solo a identidades individuales o grupos de identidades individuales, nunca a buzones o cuentas compartidas. 4) En sistemas operativos del CDE, use OS Login, Entra ID login o SSSD/AD para que cada sesión SSH/RDP corresponda a un usuario nominal y no a cuentas como ec2-user o Administrator compartidas. 5) Verifique que CloudTrail, Entra sign-in logs y Cloud Audit Logs registren el principal individual. Evidencia para el QSA: inventario de identidades con dueño, configuración de federación y extractos de bitácoras que muestren acciones atribuibles a personas.", "descripcion_corta_en": "Unique ID assigned to every user before accessing system components or cardholder data", "descripcion_larga_en": "Every user must be given an individual identifier of their own before being allowed to access any system component or cardholder data. The goal is that every action performed in the environment can be traced back to a specific person, which is validated by reviewing audit logs and other evidence. It does not apply to user accounts on point-of-sale terminals that access only one card number at a time to process a single transaction.", "remediacion_en": "1) Centralize identity in an identity provider (federated AWS IAM Identity Center, Microsoft Entra ID, Google Workspace/Cloud Identity) and issue one named account per person; avoid local IAM users and generic accounts. 2) Do not use the AWS root user for daily operations: delete its access keys, enable MFA and alert on any usage. 3) In Azure and GCP, grant roles only to individual identities or groups of individuals, never to shared mailboxes or shared accounts. 4) On CDE operating systems, use OS Login, Entra ID login or SSSD/AD so each SSH/RDP session maps to a named user instead of shared accounts such as ec2-user or Administrator. 5) Confirm that CloudTrail, Entra sign-in logs and Cloud Audit Logs record the individual principal. QSA evidence: identity inventory with owners, federation configuration and log extracts showing actions attributable to individuals.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 182, "pagina_pdf_es": 194 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Uso de la cuenta root en los últimos 90 días según CloudTrail (userIdentity.type = Root) (falla si existe) [CloudWatch.1]", "Llaves de acceso activas en la cuenta root (falla si existen) [IAM.4]", "Usuarios IAM con contraseña de consola cuando existe IAM Identity Center/federación (alerta: identidades fuera del IdP central)", "Snapshots EC2: /etc/passwd con más de una cuenta UID 0 o cuentas genéricas con shell interactivo (falla si existe)" ], "checks_azure": [ "Entra ID: usuarios con nombres genéricos (admin, soporte, ops, test) habilitados para inicio de sesión (alerta)", "Asignaciones de rol Azure RBAC a cuentas no nominales o invitados sin dueño (alerta)", "Snapshots de VM: cuentas locales compartidas habilitadas (falla si existe)" ], "checks_gcp": [ "IAM: bindings a cuentas de usuario genéricas o a grupos de Google con buzón compartido (alerta)", "Compute Engine: metadato enable-oslogin = TRUE a nivel proyecto/instancia (falla si no)", "Uso humano de la cuenta de servicio predeterminada de Compute en Cloud Audit Logs (falla si existe)" ], "evidencia": "Inventario de identidades por nube con dueño asignado, eventos de uso de root, configuración de federación/SSO y muestras de bitácoras que vinculan acciones con personas.", "evidencia_en": "Per-cloud identity inventory with assigned owners, root usage events, federation/SSO configuration and log samples linking actions to individuals.", "limitaciones": "El escaneo no puede confirmar que una cuenta aparentemente nominal no sea usada por varias personas; se requiere entrevista y revisión del proceso de alta.", "limitaciones_en": "The scan cannot confirm that a seemingly named account is not used by several people; interviews and review of the onboarding process are required.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.16", "5.17", "8.5" ], "soc2_tsc": [ "CC6.1", "CC6.2" ], "cis_controls_v8": [ "5.1", "5.6", "6.7" ] }, "mapeo_ucf": [ { "clave": "UCF-IAM-001", "relacion": "equivalent", "cobertura_pct": 100 } ] }, { "id": 108, "numero_regla": "8.2.2", "requisito": "8", "seccion": "8.2", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Identificación de usuarios y ciclo de vida de cuentas gestionados estrictamente", "seccion_titulo_en": "User identification and account lifecycle are strictly managed", "descripcion_corta": "IDs de grupo, compartidos o genéricos usados solo por excepción y con atribución individual", "descripcion_larga": "Las cuentas de grupo, compartidas o genéricas, y cualquier credencial de autenticación compartida, solo pueden emplearse cuando sea indispensable y de forma excepcional. Su uso debe estar bloqueado salvo en la circunstancia excepcional, limitado al tiempo necesario, con justificación de negocio documentada y aprobación explícita de la dirección. Antes de otorgar el acceso se confirma la identidad de la persona y cada acción ejecutada debe poder atribuirse a un usuario individual. No aplica a cuentas de terminales de punto de venta que solo acceden a un número de tarjeta a la vez para una transacción.", "remediacion": "1) Trate la cuenta root de AWS, el Global Administrator de emergencia de Entra ID y el super administrador de Google como cuentas de 'romper el cristal': credenciales en bóveda con doble custodia, MFA de hardware y sin llaves de acceso. 2) Configure alarmas (CloudWatch/EventBridge sobre CloudTrail, alertas de Entra, alertas de Workspace) para cualquier inicio de sesión de estas cuentas. 3) Para cuentas compartidas inevitables (p. ej. administradores locales de bases de datos), use una bóveda de contraseñas o PAM con check-out individual, aprobación, tiempo limitado y rotación al devolverla. 4) Mantenga un registro de excepciones con justificación, aprobación de la dirección, ventana de uso y persona que la usó. 5) Correlacione cada uso con el ticket y la persona. Evidencia: política de cuentas compartidas, registro de excepciones aprobadas, bitácoras de check-out de la bóveda y alertas de uso de root/break-glass.", "descripcion_corta_en": "Group, shared or generic IDs used only by exception with individual accountability", "descripcion_larga_en": "Group, shared or generic accounts, and any shared authentication credentials, may be used only when strictly necessary and on an exception basis. Their use must be blocked except during the exceptional circumstance, limited to the time required, backed by documented business justification and explicitly approved by management. The individual's identity is confirmed before access is granted and every action taken must be attributable to an individual user. It does not apply to point-of-sale terminal accounts that access only one card number at a time for a single transaction.", "remediacion_en": "1) Treat the AWS root user, Entra ID emergency Global Administrator and Google super administrator as break-glass accounts: credentials vaulted with dual custody, hardware MFA and no access keys. 2) Configure alerts (CloudWatch/EventBridge on CloudTrail, Entra alerts, Workspace alerts) for any sign-in by these accounts. 3) For unavoidable shared accounts (e.g., local database administrators), use a password vault or PAM tool with individual check-out, approval, time limits and rotation on check-in. 4) Keep an exceptions register with justification, management approval, usage window and the person who used it. 5) Correlate each use with the ticket and the person. Evidence: shared-account policy, approved exceptions register, vault check-out logs and root/break-glass usage alerts.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 183, "pagina_pdf_es": 195 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Llaves de acceso en la cuenta root (falla si existen) [IAM.4]", "MFA habilitado en la cuenta root (falla si no) [IAM.9]; MFA de hardware en root [IAM.6]", "Filtro de métricas y alarma para uso de la cuenta root (falla si no existe) [CloudWatch.1]", "Inicios de sesión de root en CloudTrail sin ticket de excepción asociado (alerta)" ], "checks_azure": [ "Cuentas de acceso de emergencia de Entra ID: número de Global Administrators permanentes > 5 o sin MFA (falla)", "Alertas configuradas para inicio de sesión de cuentas break-glass en Log Analytics/Sentinel (falla si no)", "Cuentas de usuario compartidas (buzones compartidos) con inicio de sesión habilitado (falla si existe)" ], "checks_gcp": [ "Número de super administradores de Google Workspace/Cloud Identity y 2SV aplicado en ellos (falla si sin 2SV)", "Llaves de cuentas de servicio descargadas usadas desde IP de usuario final (alerta)", "Política de organización iam.disableServiceAccountKeyCreation aplicada (alerta si no)" ], "evidencia": "Registro de excepciones de cuentas compartidas con aprobación, bitácoras de check-out de la bóveda/PAM, alertas de uso de root/break-glass y su correlación con tickets.", "evidencia_en": "Shared-account exceptions register with approvals, vault/PAM check-out logs, root/break-glass usage alerts and their correlation with tickets.", "limitaciones": "El escaneo detecta cuentas privilegiadas compartidas y su uso, pero no puede verificar la justificación, la aprobación de la dirección ni la confirmación de identidad previa.", "limitaciones_en": "The scan detects shared privileged accounts and their usage but cannot verify justification, management approval or prior identity confirmation.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.16", "5.17", "8.2" ], "soc2_tsc": [ "CC6.1", "CC6.2", "CC6.3" ], "cis_controls_v8": [ "5.4", "4.7", "6.5" ] } }, { "id": 109, "numero_regla": "8.2.3", "requisito": "8", "seccion": "8.2", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Identificación de usuarios y ciclo de vida de cuentas gestionados estrictamente", "seccion_titulo_en": "User identification and account lifecycle are strictly managed", "descripcion_corta": "Proveedores de servicios usan factores de autenticación únicos por cada instalación de cliente", "descripcion_larga": "Requisito adicional solo para proveedores de servicios: cuando tienen acceso remoto a las instalaciones de sus clientes, deben usar factores de autenticación distintos para cada cliente, de modo que una credencial comprometida no sirva para entrar a otros clientes. Mecanismos que generan una credencial única por conexión, como contraseñas de un solo uso, también cumplen la intención. No aplica cuando el proveedor accede a sus propios entornos de servicios compartidos donde se alojan varios clientes. Si su personal usa factores compartidos para acceder remotamente a clientes, estos deben ser únicos por cliente y gestionarse conforme a 8.2.2.", "remediacion": "1) Inventaríe todos los accesos remotos a entornos de clientes (roles entre cuentas de AWS, Azure Lighthouse, delegaciones de GCP, VPN, bastiones). 2) Use un rol o identidad distinto por cliente: en AWS, roles de confianza entre cuentas con ExternalId único por cliente; en Azure, delegaciones de Lighthouse por inquilino; en GCP, cuentas o grupos distintos por organización del cliente. 3) Prohíba llaves SSH, certificados o contraseñas reutilizados entre clientes; almacénelos en una bóveda separada por cliente y rótelos. 4) Prefiera MFA con OTP o factores de un solo uso por conexión. 5) Documente el procedimiento y conserve el inventario de credenciales por cliente. Evidencia: política de autenticación para acceso a clientes, inventario de credenciales por cliente y configuración de roles/ExternalId.", "descripcion_corta_en": "Service providers use unique authentication factors for each customer premises", "descripcion_larga_en": "Additional requirement for service providers only: when they have remote access to customer premises, they must use different authentication factors for each customer, so that a compromised credential cannot be used to reach other customers. Mechanisms that generate a unique credential per connection, such as one-time passwords, also meet the intent. It does not apply when the provider accesses its own shared services environments hosting multiple customers. If provider staff use shared factors to remotely access customers, those factors must be unique per customer and managed in line with 8.2.2.", "remediacion_en": "1) Inventory all remote access paths into customer environments (AWS cross-account roles, Azure Lighthouse, GCP delegations, VPNs, bastions). 2) Use a distinct role or identity per customer: in AWS, cross-account trust roles with a unique ExternalId per customer; in Azure, per-tenant Lighthouse delegations; in GCP, separate accounts or groups per customer organization. 3) Prohibit SSH keys, certificates or passwords reused across customers; store them in a per-customer vault and rotate them. 4) Prefer MFA with OTP or per-connection single-use factors. 5) Document the procedure and keep the per-customer credential inventory. Evidence: authentication policy for customer access, per-customer credential inventory and role/ExternalId configuration.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 184, "pagina_pdf_es": 197 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Procedimiento de acceso remoto a clientes, inventario de credenciales por cliente y evidencia de unicidad (roles/ExternalId, llaves distintas, OTP).", "evidencia_en": "Customer remote access procedure, per-customer credential inventory and proof of uniqueness (roles/ExternalId, distinct keys, OTP).", "limitaciones": "Kyber escanea la nube del cliente evaluado, no las instalaciones de terceros a las que accede el proveedor; la unicidad de credenciales entre clientes debe demostrarse documentalmente.", "limitaciones_en": "Kyber scans the assessed entity's cloud, not the third-party premises the provider accesses; credential uniqueness across customers must be demonstrated through documentation.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.17", "5.20", "8.5" ], "soc2_tsc": [ "CC6.1", "CC9.2" ], "cis_controls_v8": [ "5.2", "6.4" ] } }, { "id": 110, "numero_regla": "8.2.4", "requisito": "8", "seccion": "8.2", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Identificación de usuarios y ciclo de vida de cuentas gestionados estrictamente", "seccion_titulo_en": "User identification and account lifecycle are strictly managed", "descripcion_corta": "Altas, bajas y cambios de IDs y factores de autenticación autorizados y con privilegios aprobados", "descripcion_larga": "La creación, eliminación y modificación de IDs de usuario, factores de autenticación y otros objetos de identificación deben contar con la aprobación correspondiente. Además, deben implementarse otorgando únicamente los privilegios indicados en la aprobación documentada. Aplica a todas las cuentas de usuario, incluidos empleados, contratistas, consultores, trabajadores temporales y proveedores externos.", "remediacion": "1) Defina un flujo de solicitud y aprobación (ITSM) para altas, bajas y cambios de identidades y permisos, y aprovisione desde el IdP mediante SCIM o infraestructura como código revisada (Terraform con pull request aprobado). 2) Use grupos y conjuntos de permisos (IAM Identity Center permission sets, grupos de Entra con Access Packages, grupos de Google) en lugar de permisos directos. 3) Habilite alertas sobre cambios de IAM: filtro de métricas de CloudTrail para cambios de políticas IAM, alertas de Entra audit logs y Cloud Audit Logs (SetIamPolicy). 4) Concilie mensualmente los eventos de cambio contra tickets aprobados y corrija desviaciones. Evidencia: muestras de tickets aprobados vs. eventos de CloudTrail/Entra/Cloud Audit Logs, y reporte de conciliación.", "descripcion_corta_en": "User ID and authentication factor additions, deletions and changes are authorized with approved privileges", "descripcion_larga_en": "The creation, deletion and modification of user IDs, authentication factors and other identifier objects must carry the appropriate approval. They must also be implemented granting only the privileges stated in the documented approval. It applies to all user accounts, including employees, contractors, consultants, temporary workers and third-party vendors.", "remediacion_en": "1) Define a request and approval workflow (ITSM) for identity and permission additions, removals and changes, and provision from the IdP via SCIM or reviewed infrastructure as code (Terraform with approved pull requests). 2) Use groups and permission sets (IAM Identity Center permission sets, Entra groups with Access Packages, Google groups) instead of direct permissions. 3) Enable alerts on IAM changes: CloudTrail metric filter for IAM policy changes, Entra audit log alerts and Cloud Audit Logs (SetIamPolicy). 4) Reconcile change events against approved tickets monthly and fix deviations. Evidence: samples of approved tickets vs. CloudTrail/Entra/Cloud Audit Logs events, and a reconciliation report.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 186, "pagina_pdf_es": 198 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Filtro de métricas y alarma para cambios de políticas IAM (falla si no existe) [CloudWatch.4]", "Listado de eventos CreateUser, AttachUserPolicy, CreateAccessKey, CreateLoginProfile, PutRolePolicy del periodo para conciliar con tickets", "Usuarios IAM con políticas adjuntas directamente en lugar de grupos/roles (falla si existe) [IAM.2]" ], "checks_azure": [ "Listado de eventos de Entra audit logs (Add user, Add member to role, Update authentication methods) del periodo", "Asignaciones de rol privilegiado permanentes fuera de PIM (alerta)", "Alertas de Azure Monitor para operaciones Microsoft.Authorization/roleAssignments/write (falla si no existen)" ], "checks_gcp": [ "Listado de eventos SetIamPolicy y CreateServiceAccountKey en Cloud Audit Logs del periodo", "Roles IAM otorgados directamente a usuarios en lugar de grupos (alerta)", "Alerta de Cloud Monitoring sobre cambios de IAM a nivel organización/proyecto (falla si no existe)" ], "evidencia": "Kyber genera el listado de eventos de ciclo de vida de identidades y permisos; el cliente aporta los tickets de aprobación para conciliar.", "evidencia_en": "Kyber produces the list of identity and permission lifecycle events; the customer provides approval tickets for reconciliation.", "limitaciones": "El escaneo no puede saber si un cambio fue aprobado ni si los privilegios coinciden con lo solicitado sin acceso al sistema de tickets.", "limitaciones_en": "The scan cannot tell whether a change was approved or whether privileges match the request without access to the ticketing system.", "responsabilidad_compartida": "cliente", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.16", "5.18", "8.2" ], "soc2_tsc": [ "CC6.2", "CC6.3" ], "cis_controls_v8": [ "6.1", "6.2", "5.6" ] } }, { "id": 111, "numero_regla": "8.2.5", "requisito": "8", "seccion": "8.2", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Identificación de usuarios y ciclo de vida de cuentas gestionados estrictamente", "seccion_titulo_en": "User identification and account lifecycle are strictly managed", "descripcion_corta": "Revocación inmediata del acceso de usuarios dados de baja", "descripcion_larga": "Cuando una persona deja la organización o termina su relación, su acceso debe revocarse de inmediato. Se verifica que los IDs de usuarios dados de baja estén desactivados o eliminados de las listas de acceso, tanto locales como remotas, y que los factores de autenticación físicos (tarjetas inteligentes, tokens, etc.) hayan sido devueltos o desactivados.", "remediacion": "1) Integre el sistema de RR. HH. con el IdP (Entra ID, Okta, Google Workspace) para que la baja desactive automáticamente la cuenta y propague el deprovisioning por SCIM a AWS IAM Identity Center y aplicaciones. 2) Revoque sesiones y tokens activos (Revoke-MgUserSignInSession en Entra, cierre de sesión forzado en Google, revocación de sesiones de rol en AWS). 3) Elimine o desactive usuarios IAM locales, llaves de acceso, llaves SSH y cuentas en bases de datos y sistemas operativos del CDE. 4) Recupere o desactive tokens de hardware y certificados. 5) Concilie al menos mensualmente la lista de bajas de RR. HH. contra todas las identidades activas en las tres nubes. Evidencia: listado de bajas, conciliación con identidades activas y bitácoras de desactivación con fecha y hora.", "descripcion_corta_en": "Immediate revocation of access for terminated users", "descripcion_larga_en": "When a person leaves the organization or the relationship ends, their access must be revoked immediately. It is verified that terminated user IDs have been deactivated or removed from access lists, both local and remote, and that physical authentication factors (smart cards, tokens, etc.) have been returned or deactivated.", "remediacion_en": "1) Integrate the HR system with the IdP (Entra ID, Okta, Google Workspace) so a termination automatically disables the account and SCIM deprovisioning reaches AWS IAM Identity Center and applications. 2) Revoke active sessions and tokens (Revoke-MgUserSignInSession in Entra, forced sign-out in Google, role session revocation in AWS). 3) Remove or disable local IAM users, access keys, SSH keys and accounts in CDE databases and operating systems. 4) Recover or deactivate hardware tokens and certificates. 5) Reconcile the HR termination list against all active identities across the three clouds at least monthly. Evidence: termination list, reconciliation against active identities and timestamped deactivation logs.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 186, "pagina_pdf_es": 199 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Inventario de usuarios IAM, usuarios de IAM Identity Center y llaves de acceso activas con última actividad, para conciliar contra bajas de RR. HH.", "Usuarios de IAM Identity Center no aprovisionados por SCIM desde el IdP (alerta)", "Llaves SSH autorizadas en snapshots (~/.ssh/authorized_keys) de usuarios inexistentes en el IdP (alerta)" ], "checks_azure": [ "Inventario de usuarios de Entra ID habilitados (accountEnabled = true) con fecha de último inicio de sesión para conciliar contra bajas", "Usuarios invitados (guest) activos sin patrocinador o sin revisión de acceso (alerta)", "Asignaciones de rol Azure RBAC a identidades eliminadas (objetos huérfanos) (falla si existen)" ], "checks_gcp": [ "Inventario de usuarios de Cloud Identity/Workspace activos y bindings IAM por proyecto para conciliar contra bajas", "Bindings IAM a cuentas eliminadas (deleted:user:...) (falla si existen)", "Llaves SSH en metadatos de proyecto/instancia de usuarios no existentes (alerta)" ], "evidencia": "Kyber genera el inventario de identidades activas por nube; el cliente aporta la lista de bajas de RR. HH. y la evidencia de devolución de tokens físicos.", "evidencia_en": "Kyber generates the active identity inventory per cloud; the customer provides the HR termination list and proof of physical token return.", "limitaciones": "Kyber no conoce qué personas fueron dadas de baja ni la oportunidad de la revocación sin la fuente de RR. HH.; tampoco cubre tokens físicos.", "limitaciones_en": "Kyber does not know which people were terminated or how promptly access was revoked without the HR source; physical tokens are not covered.", "responsabilidad_compartida": "cliente", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.18", "6.5", "5.16" ], "soc2_tsc": [ "CC6.2", "CC6.3" ], "cis_controls_v8": [ "6.2", "5.3" ] }, "mapeo_ucf": [ { "clave": "UCF-IAM-003", "relacion": "equivalent", "cobertura_pct": 100 } ] }, { "id": 112, "numero_regla": "8.2.6", "requisito": "8", "seccion": "8.2", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Identificación de usuarios y ciclo de vida de cuentas gestionados estrictamente", "seccion_titulo_en": "User identification and account lifecycle are strictly managed", "descripcion_corta": "Cuentas de usuario inactivas eliminadas o deshabilitadas en un máximo de 90 días", "descripcion_larga": "Las cuentas de usuario que no hayan registrado actividad deben eliminarse o deshabilitarse a más tardar a los 90 días de inactividad. Se verifica revisando las cuentas y la información de su último inicio de sesión. Como buena práctica, si se anticipa una ausencia prolongada, la cuenta debería deshabilitarse desde el inicio de la ausencia.", "remediacion": "1) En AWS, deshabilite contraseñas de consola y llaves de acceso de usuarios IAM sin uso en 90 días (o 45 días según CIS) usando el credential report y una automatización (Lambda/Config remediation). 2) En IAM Identity Center y en el IdP, deshabilite usuarios sin inicio de sesión en 90 días. 3) En Entra ID, use Access Reviews con detección de inactividad o un runbook que consulte signInActivity y deshabilite cuentas. 4) En Google Workspace, use el reporte de último inicio de sesión y suspenda cuentas inactivas; en GCP, use IAM Recommender para quitar roles y llaves de cuentas de servicio sin uso. 5) En sistemas operativos y bases de datos del CDE, configure expiración por inactividad (INACTIVE en /etc/default/useradd). Evidencia: credential report, reporte de último inicio de sesión y bitácoras de deshabilitación.", "descripcion_corta_en": "Inactive user accounts removed or disabled within 90 days", "descripcion_larga_en": "User accounts with no activity must be removed or disabled no later than 90 days after becoming inactive. This is validated by reviewing the accounts and their last logon information. As good practice, if a long absence is anticipated, the account should be disabled as soon as the absence starts.", "remediacion_en": "1) In AWS, disable console passwords and access keys of IAM users unused for 90 days (or 45 days per CIS) using the credential report and automation (Lambda/Config remediation). 2) In IAM Identity Center and the IdP, disable users with no sign-in in 90 days. 3) In Entra ID, use Access Reviews with inactivity detection or a runbook querying signInActivity to disable accounts. 4) In Google Workspace, use the last login report and suspend inactive accounts; in GCP, use IAM Recommender to remove unused roles and service account keys. 5) On CDE operating systems and databases, set inactivity expiry (INACTIVE in /etc/default/useradd). Evidence: credential report, last sign-in report and disablement logs.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 187, "pagina_pdf_es": 199 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Credential report: usuarios IAM con contraseña o llave de acceso sin uso > 90 días (falla) [IAM.8]", "Credenciales de usuarios IAM sin uso > 45 días (CIS) [IAM.22]", "Usuarios de IAM Identity Center sin inicio de sesión > 90 días (falla)" ], "checks_azure": [ "Entra ID: usuarios habilitados con signInActivity.lastSignInDateTime > 90 días (falla)", "Usuarios invitados inactivos > 90 días (falla)", "Asignaciones de rol privilegiado a cuentas sin inicio de sesión > 90 días (falla)" ], "checks_gcp": [ "Google Workspace/Cloud Identity: usuarios activos con lastLoginTime > 90 días (falla)", "Llaves de cuentas de servicio administradas por el usuario sin autenticación > 90 días (falla)", "IAM Recommender: roles sin uso en 90 días otorgados a usuarios (alerta)" ], "evidencia": "Reporte generado de cuentas con último inicio de sesión y su estado, más bitácoras de deshabilitación automática.", "evidencia_en": "Generated report of accounts with last sign-in and status, plus automatic disablement logs.", "limitaciones": "Las cuentas locales de aplicaciones o bases de datos dentro del CDE requieren evidencia adicional; los snapshots no siempre reflejan el último inicio de sesión real.", "limitaciones_en": "Local application or database accounts inside the CDE require additional evidence; snapshots do not always reflect the actual last sign-in.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.18", "5.16" ], "soc2_tsc": [ "CC6.2" ], "cis_controls_v8": [ "5.3" ], "banxico_spei": [ "58a. I.A.e).2" ] } }, { "id": 113, "numero_regla": "8.2.7", "requisito": "8", "seccion": "8.2", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Identificación de usuarios y ciclo de vida de cuentas gestionados estrictamente", "seccion_titulo_en": "User identification and account lifecycle are strictly managed", "descripcion_corta": "Cuentas de terceros para acceso remoto habilitadas solo cuando se necesitan y monitoreadas", "descripcion_larga": "Las cuentas que terceros usan para acceder, dar soporte o mantener componentes del sistema mediante acceso remoto deben estar habilitadas únicamente durante el periodo requerido y deshabilitarse cuando no se utilicen. Además, su uso debe monitorearse para detectar actividad inesperada. Si un tercero necesita acceso permanente, debe documentarse, justificarse y vincularse a razones de servicio concretas.", "remediacion": "1) Inventaríe accesos de terceros: roles entre cuentas en AWS con principals externos, usuarios invitados y delegaciones de Azure Lighthouse en Entra/Azure, y miembros de dominios externos en GCP. 2) Otorgue acceso just-in-time: Entra PIM con activación aprobada y duración limitada, Access Packages con fecha de expiración, condiciones IAM con expiración (request.time) en GCP, y roles AWS asumibles solo tras aprobación (o deshabilitando la política de confianza cuando no se usan). 3) Monitoree el uso con alertas de CloudTrail (AssumeRole desde cuentas externas), Entra sign-in logs de invitados y Cloud Audit Logs, y revise actividad fuera de ventanas aprobadas. 4) Asigne fecha de inicio y fin conforme al contrato. Evidencia: inventario de cuentas de terceros, configuración JIT/expiración y reportes de monitoreo.", "descripcion_corta_en": "Third-party remote access accounts enabled only when needed and monitored", "descripcion_larga_en": "Accounts used by third parties to access, support or maintain system components via remote access must be enabled only for the period required and disabled when not in use. Their use must also be monitored for unexpected activity. If a third party needs permanent access, it must be documented, justified and tied to specific service reasons.", "remediacion_en": "1) Inventory third-party access: AWS cross-account roles with external principals, guest users and Azure Lighthouse delegations in Entra/Azure, and external-domain members in GCP. 2) Grant just-in-time access: Entra PIM with approved, time-bound activation, Access Packages with expiry, IAM conditions with expiry (request.time) in GCP, and AWS roles assumable only after approval (or disabling the trust policy when unused). 3) Monitor use with CloudTrail alerts (AssumeRole from external accounts), Entra guest sign-in logs and Cloud Audit Logs, and review activity outside approved windows. 4) Set start and end dates aligned with the contract. Evidence: third-party account inventory, JIT/expiry configuration and monitoring reports.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 187, "pagina_pdf_es": 200 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "IAM Access Analyzer: roles con políticas de confianza a cuentas externas (inventario y alerta si sin etiqueta de dueño/expiración)", "Roles de terceros con AssumeRole fuera de la ventana aprobada o sin uso > 90 días (alerta)", "Usuarios IAM etiquetados como terceros con llaves de acceso activas permanentes (falla)" ], "checks_azure": [ "Entra ID: usuarios invitados con roles privilegiados permanentes fuera de PIM (falla)", "Delegaciones de Azure Lighthouse activas y su alcance (inventario)", "Access Packages/asignaciones de invitados sin fecha de expiración (alerta)" ], "checks_gcp": [ "IAM: miembros de dominios externos a la organización con roles en proyectos del CDE (alerta)", "Política de organización iam.allowedPolicyMemberDomains aplicada (falla si no)", "Bindings de terceros sin condición de expiración (alerta)" ], "evidencia": "Inventario generado de accesos de terceros con su vigencia y reportes de actividad; el cliente aporta contratos y aprobaciones de ventanas de acceso.", "evidencia_en": "Generated inventory of third-party access with validity periods and activity reports; the customer provides contracts and access window approvals.", "limitaciones": "No puede determinar qué periodo es 'necesario' ni identificar terceros que usan cuentas nominales no etiquetadas; el monitoreo de actividad inesperada depende del SIEM del cliente.", "limitaciones_en": "It cannot determine which period is 'needed' or identify third parties using untagged named accounts; monitoring for unexpected activity depends on the customer's SIEM.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.19", "5.20", "8.2", "8.16" ], "soc2_tsc": [ "CC6.1", "CC6.2", "CC9.2" ], "cis_controls_v8": [ "6.1", "6.2", "13.5" ] } }, { "id": 114, "numero_regla": "8.2.8", "requisito": "8", "seccion": "8.2", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Identificación de usuarios y ciclo de vida de cuentas gestionados estrictamente", "seccion_titulo_en": "User identification and account lifecycle are strictly managed", "descripcion_corta": "Reautenticación tras más de 15 minutos de inactividad en la sesión", "descripcion_larga": "Si una sesión de usuario permanece inactiva por más de 15 minutos, la persona debe volver a autenticarse para reactivar la terminal o la sesión. Se verifica que los parámetros de tiempo de inactividad del sistema o de la sesión estén configurados en 15 minutos o menos. No aplica a cuentas de terminales de punto de venta que solo acceden a un número de tarjeta a la vez, y no pretende impedir actividades legítimas que se ejecuten mientras el equipo está desatendido.", "remediacion": "1) AWS Systems Manager Session Manager: configure idleSessionTimeout en 15 minutos o menos en el documento de preferencias (SSM-SessionManagerRunShell). 2) En instancias Linux del CDE, defina TMOUT=900 (readonly) en /etc/profile.d y ClientAliveInterval/ClientAliveCountMax en sshd_config que no excedan 900 segundos; en Windows, bloqueo de pantalla y límite de sesión RDP inactiva de 15 minutos por GPO/Intune. 3) Consola de AWS: use IAM Identity Center con duración de sesión corta y roles con MaxSessionDuration acorde, y complemente con bloqueo de pantalla del endpoint de 15 minutos. 4) Azure: configure el tiempo de inactividad del portal a nivel directorio (15 minutos) y Conditional Access sign-in frequency; Azure Bastion y AVD con límites de sesión inactiva. 5) GCP: configure Google Cloud session control (frecuencia de reautenticación) y bloqueo de endpoints. Evidencia: capturas o exportes de configuración de cada mecanismo de timeout.", "descripcion_corta_en": "Re-authentication after more than 15 minutes of session inactivity", "descripcion_larga_en": "If a user session stays idle for more than 15 minutes, the person must re-authenticate to reactivate the terminal or session. It is verified that system or session idle-timeout parameters are set to 15 minutes or less. It does not apply to point-of-sale terminal accounts that access only one card number at a time, and it is not meant to prevent legitimate activities running while the console is unattended.", "remediacion_en": "1) AWS Systems Manager Session Manager: set idleSessionTimeout to 15 minutes or less in the preferences document (SSM-SessionManagerRunShell). 2) On CDE Linux instances, set TMOUT=900 (readonly) in /etc/profile.d and ClientAliveInterval/ClientAliveCountMax in sshd_config not exceeding 900 seconds; on Windows, 15-minute screen lock and idle RDP session limit via GPO/Intune. 3) AWS console: use IAM Identity Center with a short session duration and roles with an appropriate MaxSessionDuration, complemented by a 15-minute endpoint screen lock. 4) Azure: set the directory-level portal inactivity timeout (15 minutes) and Conditional Access sign-in frequency; Azure Bastion and AVD with idle session limits. 5) GCP: configure Google Cloud session control (reauthentication frequency) and endpoint locking. Evidence: screenshots or exports of each timeout mechanism's configuration.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 189, "pagina_pdf_es": 201 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Session Manager: idleSessionTimeout <= 15 minutos en SSM-SessionManagerRunShell (falla si mayor o no definido)", "Snapshots EC2 Linux: TMOUT <= 900 en /etc/profile o /etc/profile.d (falla si ausente o mayor)", "Snapshots EC2 Linux: ClientAliveInterval x ClientAliveCountMax <= 900 en sshd_config (falla si mayor)", "IAM Identity Center: duración de sesión configurada y roles con MaxSessionDuration > 1 hora en cuentas del CDE (alerta)" ], "checks_azure": [ "Azure portal: tiempo de inactividad configurado a nivel directorio <= 15 minutos (falla si no)", "Conditional Access: política de sign-in frequency para aplicaciones de administración (alerta si no existe)", "Snapshots de VM Linux: TMOUT y parámetros de sshd <= 900 segundos (falla si mayor)" ], "checks_gcp": [ "Google Cloud session control: reautenticación configurada para usuarios con acceso al CDE (alerta si no)", "Snapshots de Compute Engine Linux: TMOUT <= 900 y ClientAliveInterval acorde (falla si mayor)", "IAP/OS Login en uso para SSH en lugar de llaves en metadatos (alerta si no)" ], "evidencia": "Configuración exportada de timeouts de Session Manager, portal de Azure, controles de sesión de Google y parámetros de SO extraídos de snapshots.", "evidencia_en": "Exported timeout configuration for Session Manager, Azure portal, Google session controls and OS parameters extracted from snapshots.", "limitaciones": "La consola de AWS no ofrece un timeout de inactividad configurable; el bloqueo de pantalla de los endpoints de usuario y las aplicaciones web propias quedan fuera del escaneo agentless.", "limitaciones_en": "The AWS console has no configurable idle timeout; user endpoint screen locks and custom web applications are outside the agentless scan.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.5", "7.7", "8.1" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "4.3" ], "banxico_spei": [ "58a. I.A.e).3", "58a. I.C.d)" ] } }, { "id": 115, "numero_regla": "8.3.1", "requisito": "8", "seccion": "8.3", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Autenticación fuerte establecida y gestionada", "seccion_titulo_en": "Strong authentication is established and managed", "descripcion_corta": "Todo acceso de usuarios y administradores se autentica con al menos un factor de autenticación", "descripcion_larga": "Todo acceso de usuarios y administradores a los componentes del sistema debe autenticarse con al menos un factor: algo que se sabe (contraseña o frase de paso), algo que se tiene (token o tarjeta inteligente) o algo que se es (biométrico). Este requisito no sustituye los requisitos de MFA, sino que aplica a los sistemas dentro del alcance no sujetos a MFA. Un certificado digital es válido como 'algo que se tiene' si es único para un usuario. No aplica a cuentas de terminales de punto de venta que solo acceden a un número de tarjeta a la vez.", "remediacion": "1) Elimine cualquier acceso sin autenticación a componentes del CDE: endpoints de API Gateway con authorizationType NONE, URLs de funciones Lambda con AuthType NONE, servicios de Cloud Run con allUsers como invocador y recursos públicos en Azure. 2) Prohíba contraseñas vacías y accesos anónimos en sistemas operativos y bases de datos (PermitEmptyPasswords no, cuentas sin hash en /etc/shadow, usuarios anónimos de MySQL). 3) Use IAM Database Authentication o autenticación de Entra/IAM para bases de datos administradas donde sea posible. 4) Documente los factores usados por tipo de componente. Evidencia: documentación de factores de autenticación y configuraciones que demuestren que no hay acceso anónimo.", "descripcion_corta_en": "All user and administrator access is authenticated with at least one authentication factor", "descripcion_larga_en": "All user and administrator access to system components must be authenticated with at least one factor: something you know (password or passphrase), something you have (token or smart card) or something you are (biometric). This requirement does not replace MFA requirements but applies to in-scope systems not otherwise subject to MFA. A digital certificate is valid as 'something you have' if it is unique to a user. It does not apply to point-of-sale terminal accounts that access only one card number at a time.", "remediacion_en": "1) Remove any unauthenticated access to CDE components: API Gateway methods with authorizationType NONE, Lambda function URLs with AuthType NONE, Cloud Run services with allUsers as invoker and public resources in Azure. 2) Prohibit empty passwords and anonymous access on operating systems and databases (PermitEmptyPasswords no, accounts without hash in /etc/shadow, anonymous MySQL users). 3) Use IAM Database Authentication or Entra/IAM authentication for managed databases where possible. 4) Document the factors used per component type. Evidence: authentication factor documentation and configurations showing no anonymous access.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 190, "pagina_pdf_es": 202 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "API Gateway: métodos con authorizationType = NONE en APIs del CDE (falla si existen)", "Lambda: URLs de función con AuthType = NONE (falla si existen)", "Snapshots EC2: cuentas con contraseña vacía en /etc/shadow o PermitEmptyPasswords yes (falla)", "RDS: autenticación IAM habilitada en instancias/clústeres del CDE (alerta si no) [RDS.10] [RDS.12]" ], "checks_azure": [ "App Service/Functions: autenticación deshabilitada en apps del CDE expuestas (alerta)", "Storage: allowBlobPublicAccess = false (falla si true)", "Azure SQL: autenticación solo de Entra ID (azureADOnlyAuthentication) o usuarios con contraseña definida (alerta)" ], "checks_gcp": [ "Cloud Run/Cloud Functions: binding roles/run.invoker o cloudfunctions.invoker a allUsers/allAuthenticatedUsers (falla)", "IAM: bindings a allUsers o allAuthenticatedUsers en recursos del CDE (falla)", "Snapshots de Compute Engine: cuentas con contraseña vacía o PermitEmptyPasswords yes (falla)" ], "evidencia": "Documentación de factores por tipo de componente y hallazgos del escaneo que confirman ausencia de acceso anónimo.", "evidencia_en": "Documentation of factors per component type and scan findings confirming no anonymous access.", "limitaciones": "No observa autenticaciones reales ni la autenticación dentro de aplicaciones propias; el QSA debe presenciar inicios de sesión por tipo de factor.", "limitaciones_en": "It does not observe real authentications or authentication inside custom applications; the QSA must witness logins per factor type.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.17", "8.5" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "5.2", "6.7" ], "banxico_spei": [ "58a. I.A.e).2" ] }, "mapeo_ucf": [ { "clave": "UCF-IAM-005", "relacion": "equivalent", "cobertura_pct": 80 } ] }, { "id": 116, "numero_regla": "8.3.2", "requisito": "8", "seccion": "8.3", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Autenticación fuerte establecida y gestionada", "seccion_titulo_en": "Strong authentication is established and managed", "descripcion_corta": "Criptografía robusta protege los factores de autenticación en tránsito y almacenamiento", "descripcion_larga": "Todos los factores de autenticación deben volverse ilegibles mediante criptografía robusta tanto al transmitirse como al almacenarse en cualquier componente del sistema. Se revisan la documentación del proveedor, las configuraciones, los repositorios de factores de autenticación y las transmisiones de datos para confirmar que no puedan obtenerse, derivarse ni reutilizarse factores en texto claro.", "remediacion": "1) Transmisión: exija TLS 1.2 o superior en balanceadores, API Gateway, CloudFront, App Service, Application Gateway y balanceadores de GCP; deshabilite protocolos en claro (Telnet, FTP, HTTP, LDAP sin TLS). 2) Almacenamiento de contraseñas de usuarios: use funciones de derivación robustas con sal (bcrypt, scrypt, Argon2, PBKDF2; SHA-512/yescrypt en /etc/shadow), nunca MD5/DES. 3) Secretos y llaves: guárdelos en AWS Secrets Manager/SSM Parameter Store SecureString con KMS, Azure Key Vault o Google Secret Manager, nunca en texto claro en variables de entorno o archivos. 4) Valide que identity pools como Cognito, Entra External ID o Identity Platform manejen el hash. Evidencia: políticas TLS, configuración de hashing y ubicación cifrada de secretos.", "descripcion_corta_en": "Strong cryptography protects authentication factors in transit and at rest", "descripcion_larga_en": "All authentication factors must be rendered unreadable with strong cryptography both when transmitted and when stored on any system component. Vendor documentation, configurations, authentication factor repositories and data transmissions are reviewed to confirm that cleartext factors cannot be obtained, derived or reused.", "remediacion_en": "1) Transmission: require TLS 1.2 or higher on load balancers, API Gateway, CloudFront, App Service, Application Gateway and GCP load balancers; disable cleartext protocols (Telnet, FTP, HTTP, LDAP without TLS). 2) User password storage: use strong salted derivation functions (bcrypt, scrypt, Argon2, PBKDF2; SHA-512/yescrypt in /etc/shadow), never MD5/DES. 3) Secrets and keys: store them in AWS Secrets Manager/SSM Parameter Store SecureString with KMS, Azure Key Vault or Google Secret Manager, never in cleartext in environment variables or files. 4) Validate that identity pools such as Cognito, Entra External ID or Identity Platform handle hashing. Evidence: TLS policies, hashing configuration and encrypted secret locations.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 191, "pagina_pdf_es": 203 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "ELB/ALB/NLB: listeners HTTP sin redirección o políticas SSL que permiten < TLS 1.2 (falla)", "SSM Parameter Store: parámetros con nombres de credenciales almacenados como String en lugar de SecureString (falla)", "Snapshots EC2: hashes en /etc/shadow con MD5 ($1$) o DES (falla); ENCRYPT_METHOD distinto de SHA512/YESCRYPT en login.defs", "Secretos en texto claro en variables de entorno de Lambda/ECS detectados por Kyber (falla)" ], "checks_azure": [ "App Service: minTlsVersion >= 1.2 y httpsOnly = true (falla si no)", "Storage: minimumTlsVersion = TLS1_2 y supportsHttpsTrafficOnly = true (falla si no)", "Snapshots de VM: hashes débiles en /etc/shadow (falla)" ], "checks_gcp": [ "Load balancers HTTPS: SSL policy con minTlsVersion TLS_1_2 y perfil MODERN/RESTRICTED (falla si no)", "Cloud SQL: settings.ipConfiguration.requireSsl / sslMode ENCRYPTED_ONLY (falla si no)", "Snapshots de Compute Engine: hashes débiles en /etc/shadow (falla)" ], "evidencia": "Configuraciones TLS exportadas, resultado del análisis de hashes en snapshots y ubicación de secretos en servicios administrados con cifrado.", "evidencia_en": "Exported TLS configurations, snapshot hash analysis results and secret locations in managed encrypted services.", "limitaciones": "No puede verificar el algoritmo de hashing de contraseñas dentro de bases de datos de aplicaciones propias ni el tráfico interno de aplicaciones sin TLS visible en configuración.", "limitaciones_en": "It cannot verify the password hashing algorithm inside custom application databases or internal application traffic whose TLS is not visible in configuration.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.24", "5.17", "8.5" ], "soc2_tsc": [ "CC6.1", "CC6.7" ], "cis_controls_v8": [ "3.10", "3.11" ] } }, { "id": 117, "numero_regla": "8.3.3", "requisito": "8", "seccion": "8.3", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Autenticación fuerte establecida y gestionada", "seccion_titulo_en": "Strong authentication is established and managed", "descripcion_corta": "Verificación de identidad del usuario antes de modificar cualquier factor de autenticación", "descripcion_larga": "Antes de cambiar cualquier factor de autenticación de un usuario, como restablecer una contraseña, emitir un nuevo token de hardware o software o generar nuevas llaves, debe verificarse la identidad de quien lo solicita. Así se evita que una persona no autorizada se haga pasar por un usuario legítimo, por ejemplo ante la mesa de ayuda.", "remediacion": "1) Habilite autoservicio de restablecimiento con verificación fuerte: Entra SSPR con dos métodos, recuperación de Google Workspace con verificación, y restablecimiento en el IdP federado a AWS IAM Identity Center. 2) Para la mesa de ayuda, defina un procedimiento de verificación (devolución de llamada a número registrado, validación del gerente, verificación por video) antes de restablecer contraseñas, MFA o llaves. 3) Registre cada restablecimiento con el método de verificación usado en el ticket. 4) Alerte sobre restablecimientos de MFA (DeactivateMFADevice en CloudTrail, cambios de métodos de autenticación en Entra audit logs). Evidencia: procedimiento documentado, muestras de tickets con verificación y configuración de SSPR.", "descripcion_corta_en": "User identity verified before modifying any authentication factor", "descripcion_larga_en": "Before changing any user authentication factor, such as resetting a password, issuing a new hardware or software token or generating new keys, the identity of the requester must be verified. This prevents an unauthorized person from impersonating a legitimate user, for example when calling the help desk.", "remediacion_en": "1) Enable self-service reset with strong verification: Entra SSPR with two methods, verified Google Workspace recovery, and reset in the IdP federated to AWS IAM Identity Center. 2) For the help desk, define a verification procedure (callback to a registered number, manager validation, video verification) before resetting passwords, MFA or keys. 3) Record each reset with the verification method used in the ticket. 4) Alert on MFA resets (DeactivateMFADevice in CloudTrail, authentication method changes in Entra audit logs). Evidence: documented procedure, ticket samples showing verification and SSPR configuration.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 192, "pagina_pdf_es": 204 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Procedimiento de verificación de identidad de la mesa de ayuda, configuración de SSPR y muestras de tickets de restablecimiento.", "evidencia_en": "Help desk identity verification procedure, SSPR configuration and reset ticket samples.", "limitaciones": "El escaneo no puede comprobar que la mesa de ayuda haya verificado la identidad antes del cambio.", "limitaciones_en": "The scan cannot confirm that the help desk verified identity before the change.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.17", "5.16" ], "soc2_tsc": [ "CC6.1", "CC6.2" ], "cis_controls_v8": [ "5.2", "6.1" ] } }, { "id": 118, "numero_regla": "8.3.4", "requisito": "8", "seccion": "8.3", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Autenticación fuerte establecida y gestionada", "seccion_titulo_en": "Strong authentication is established and managed", "descripcion_corta": "Bloqueo del ID tras máximo 10 intentos fallidos durante al menos 30 minutos", "descripcion_larga": "Los intentos de autenticación inválidos deben limitarse bloqueando el ID de usuario después de no más de 10 intentos. El bloqueo debe durar como mínimo 30 minutos o hasta que se confirme la identidad del usuario. No aplica a cuentas de terminales de punto de venta que solo acceden a un número de tarjeta a la vez.", "remediacion": "1) Los usuarios IAM de AWS no permiten configurar bloqueo de cuenta: federe el acceso a la consola mediante IAM Identity Center con un IdP que aplique bloqueo (Entra, Okta, Google). 2) Entra ID: configure Smart Lockout con lockoutThreshold <= 10 y lockoutDurationInSeconds >= 1800 (requiere Entra ID P1). 3) Amazon Cognito y aplicaciones propias: valide que el bloqueo/limitación cumpla 10 intentos y 30 minutos o implemente un control equivalente (AWS WAF con reglas de ATP/limitación de tasa). 4) Sistemas operativos del CDE: pam_faillock con deny <= 10 y unlock_time >= 1800; en Windows, política de bloqueo de cuenta por GPO. 5) Google Workspace aplica protección basada en riesgo: documente el control compensatorio o use un IdP externo con bloqueo configurable. Evidencia: configuraciones de bloqueo por cada punto de autenticación.", "descripcion_corta_en": "User ID locked out after no more than 10 failed attempts for at least 30 minutes", "descripcion_larga_en": "Invalid authentication attempts must be limited by locking the user ID after no more than 10 attempts. The lockout must last at least 30 minutes or until the user's identity is confirmed. It does not apply to point-of-sale terminal accounts that access only one card number at a time.", "remediacion_en": "1) AWS IAM users do not support configurable account lockout: federate console access through IAM Identity Center with an IdP that enforces lockout (Entra, Okta, Google). 2) Entra ID: configure Smart Lockout with lockoutThreshold <= 10 and lockoutDurationInSeconds >= 1800 (requires Entra ID P1). 3) Amazon Cognito and custom applications: confirm lockout/throttling meets 10 attempts and 30 minutes or implement an equivalent control (AWS WAF ATP/rate-based rules). 4) CDE operating systems: pam_faillock with deny <= 10 and unlock_time >= 1800; on Windows, account lockout policy via GPO. 5) Google Workspace applies risk-based protection: document the compensating control or use an external IdP with configurable lockout. Evidence: lockout configurations for every authentication point.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 193, "pagina_pdf_es": 205 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Usuarios IAM con contraseña de consola (sin bloqueo configurable) en cuentas del CDE (alerta: migrar a IdP federado)", "Snapshots EC2 Linux: pam_faillock deny <= 10 y unlock_time >= 1800 o 0 (falla si no)", "AWS WAF: regla de limitación de tasa o Account Takeover Prevention en endpoints de login públicos (alerta si no)" ], "checks_azure": [ "Entra ID Smart Lockout: lockoutThreshold <= 10 (falla si mayor)", "Entra ID Smart Lockout: lockoutDurationInSeconds >= 1800 (falla si menor)", "Snapshots de VM: pam_faillock o política de bloqueo de Windows conforme a 10/30 (falla si no)" ], "checks_gcp": [ "Snapshots de Compute Engine Linux: pam_faillock deny <= 10 y unlock_time >= 1800 (falla si no)", "Usuarios con acceso al CDE autenticados directamente en Google sin IdP con bloqueo configurable (alerta)", "Cloud Armor: regla de limitación de tasa en endpoints de login (alerta si no)" ], "evidencia": "Exporte de configuración de Smart Lockout, pam_faillock de snapshots y configuración del IdP federado.", "evidencia_en": "Export of Smart Lockout configuration, pam_faillock from snapshots and federated IdP configuration.", "limitaciones": "AWS IAM y Google Workspace no exponen umbrales de bloqueo configurables; aplicaciones propias y bases de datos requieren evidencia del cliente.", "limitaciones_en": "AWS IAM and Google Workspace do not expose configurable lockout thresholds; custom applications and databases require customer evidence.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.5", "5.17" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "4.10", "5.2" ] } }, { "id": 119, "numero_regla": "8.3.5", "requisito": "8", "seccion": "8.3", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Autenticación fuerte establecida y gestionada", "seccion_titulo_en": "Strong authentication is established and managed", "descripcion_corta": "Contraseñas iniciales y de restablecimiento únicas y con cambio obligatorio tras el primer uso", "descripcion_larga": "Cuando se usan contraseñas o frases de paso como factor de autenticación para cumplir 8.3.1, deben asignarse a cada usuario con un valor único tanto en el primer uso como al restablecerse. Además, el sistema debe obligar a cambiarlas inmediatamente después del primer uso.", "remediacion": "1) AWS: al crear o restablecer perfiles de inicio de sesión de usuarios IAM use contraseñas aleatorias únicas y PasswordResetRequired = true; habilite AllowUsersToChangePassword en la política de contraseñas. 2) Entra ID: cree usuarios con passwordProfile.forceChangePasswordNextSignIn = true y contraseñas temporales generadas, o use Temporary Access Pass de un solo uso. 3) Google Workspace: marque 'solicitar cambio de contraseña en el siguiente inicio de sesión' al crear o restablecer. 4) Sistemas operativos y bases de datos del CDE: contraseña temporal aleatoria y expiración inmediata (chage -d 0, PASSWORD EXPIRE). 5) Prohíba contraseñas iniciales estándar en el procedimiento de la mesa de ayuda. Evidencia: procedimiento y configuraciones de alta/restablecimiento.", "descripcion_corta_en": "Unique initial and reset passwords forced to change after first use", "descripcion_larga_en": "When passwords or passphrases are used as an authentication factor to meet 8.3.1, they must be set to a unique value for each user both for first-time use and upon reset. The system must also force them to be changed immediately after first use.", "remediacion_en": "1) AWS: when creating or resetting IAM user login profiles use unique random passwords and PasswordResetRequired = true; enable AllowUsersToChangePassword in the password policy. 2) Entra ID: create users with passwordProfile.forceChangePasswordNextSignIn = true and generated temporary passwords, or use a one-time Temporary Access Pass. 3) Google Workspace: tick 'ask for a password change at next sign-in' on creation or reset. 4) CDE operating systems and databases: random temporary password and immediate expiry (chage -d 0, PASSWORD EXPIRE). 5) Prohibit standard initial passwords in the help desk procedure. Evidence: procedure and creation/reset configurations.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 193, "pagina_pdf_es": 206 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Política de contraseñas IAM: AllowUsersToChangePassword = true (falla si false)", "Eventos CreateLoginProfile/UpdateLoginProfile en CloudTrail con passwordResetRequired = false (falla)", "Snapshots EC2: cuentas locales con hash de contraseña idéntico entre usuarios (falla)" ], "checks_azure": [ "Entra ID: eventos de creación/restablecimiento de usuarios sin forceChangePasswordNextSignIn (alerta)", "Temporary Access Pass configurado como de un solo uso (isUsableOnce) si está habilitado (alerta si no)", "Snapshots de VM: hashes de contraseña repetidos entre cuentas locales (falla)" ], "checks_gcp": [ "Google Workspace: usuarios creados/restablecidos sin changePasswordAtNextLogin (alerta)", "Snapshots de Compute Engine: hashes de contraseña repetidos entre cuentas locales (falla)" ], "evidencia": "Configuraciones de alta/restablecimiento por IdP y eventos de auditoría que muestren cambio obligatorio.", "evidencia_en": "Creation/reset configurations per IdP and audit events showing forced change.", "limitaciones": "No puede confirmar que el valor inicial comunicado sea único ni la práctica de la mesa de ayuda; solo infiere a partir de banderas y hashes.", "limitaciones_en": "It cannot confirm the communicated initial value is unique or the help desk practice; it only infers from flags and hashes.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.17" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "5.2" ] } }, { "id": 120, "numero_regla": "8.3.6", "requisito": "8", "seccion": "8.3", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Autenticación fuerte establecida y gestionada", "seccion_titulo_en": "Strong authentication is established and managed", "descripcion_corta": "Contraseñas de al menos 12 caracteres con letras y números", "descripcion_larga": "Cuando se usan contraseñas o frases de paso como factor para cumplir 8.3.1, deben tener como mínimo 12 caracteres (u 8 si el sistema no admite 12) y contener caracteres tanto numéricos como alfabéticos. No aplica a cuentas de terminales de punto de venta con acceso a un solo número de tarjeta a la vez ni a cuentas de aplicación o de sistema, que se rigen por la sección 8.6. Es obligatorio desde el 31 de marzo de 2025; antes de esa fecha bastaban 7 caracteres conforme a PCI DSS v3.2.1.", "remediacion": "1) AWS: configure la política de contraseñas de la cuenta con MinimumPasswordLength >= 12 (CIS recomienda 14), RequireNumbers, RequireLowercaseCharacters y RequireUppercaseCharacters. 2) Entra ID: las cuentas solo en la nube tienen un mínimo fijo de 8 caracteres; para cumplir, use autenticación sin contraseña o resistente al phishing, sincronice desde AD con Fine-Grained Password Policy de 12+, o use un IdP con longitud configurable; añada Entra Password Protection con lista de contraseñas prohibidas. 3) Google Workspace: longitud mínima >= 12 con 'aplicar política en el siguiente inicio de sesión'. 4) Sistemas operativos y bases de datos del CDE: pam_pwquality minlen >= 12 con dcredit/ucredit; Cloud SQL passwordValidationPolicy.minLength >= 12; Azure SQL/RDS con políticas equivalentes. Evidencia: exportes de políticas de contraseñas por cada sistema.", "descripcion_corta_en": "Passwords of at least 12 characters containing letters and numbers", "descripcion_larga_en": "When passwords or passphrases are used as a factor to meet 8.3.1, they must be at least 12 characters long (or 8 if the system does not support 12) and contain both numeric and alphabetic characters. It does not apply to point-of-sale terminal accounts with access to one card number at a time, nor to application or system accounts, which are governed by section 8.6. Mandatory since 31 March 2025; before that date 7 characters sufficed per PCI DSS v3.2.1.", "remediacion_en": "1) AWS: set the account password policy with MinimumPasswordLength >= 12 (CIS recommends 14), RequireNumbers, RequireLowercaseCharacters and RequireUppercaseCharacters. 2) Entra ID: cloud-only accounts have a fixed 8-character minimum; to comply, use passwordless or phishing-resistant authentication, sync from AD with a 12+ Fine-Grained Password Policy, or use an IdP with configurable length; add Entra Password Protection with a banned password list. 3) Google Workspace: minimum length >= 12 with 'enforce policy at next sign-in'. 4) CDE operating systems and databases: pam_pwquality minlen >= 12 with dcredit/ucredit; Cloud SQL passwordValidationPolicy.minLength >= 12; Azure SQL/RDS with equivalent policies. Evidence: password policy exports for each system.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 194, "pagina_pdf_es": 207 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Política de contraseñas IAM: MinimumPasswordLength >= 12, RequireNumbers y letras (falla si no) [IAM.7]", "Política de contraseñas IAM con longitud mínima >= 14 (CIS) [IAM.15]", "Snapshots EC2 Linux: pam_pwquality minlen >= 12 y dcredit/ucredit/lcredit definidos (falla si no)" ], "checks_azure": [ "Entra ID: usuarios solo en la nube con autenticación por contraseña hacia el CDE (alerta: mínimo de 8 caracteres no configurable)", "Entra Password Protection: lista personalizada de contraseñas prohibidas habilitada (alerta si no)", "Snapshots de VM: pam_pwquality minlen >= 12 o política de Windows MinimumPasswordLength >= 12 (falla si no)" ], "checks_gcp": [ "Google Workspace: longitud mínima de contraseña >= 12 y aplicación en el siguiente inicio de sesión (falla si no)", "Cloud SQL: passwordValidationPolicy.enablePasswordPolicy = true y minLength >= 12 (falla si no)", "Snapshots de Compute Engine Linux: pam_pwquality minlen >= 12 (falla si no)" ], "evidencia": "Exportes de políticas de contraseñas de IAM, Entra, Google Workspace, bases de datos y SO extraídos de snapshots.", "evidencia_en": "Password policy exports from IAM, Entra, Google Workspace, databases and OS extracted from snapshots.", "limitaciones": "No evalúa la complejidad de contraseñas en aplicaciones propias; en Entra ID solo en la nube la longitud mínima no es configurable y requiere decisión de diseño.", "limitaciones_en": "It does not evaluate password complexity in custom applications; in cloud-only Entra ID the minimum length is not configurable and requires a design decision.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.17", "8.5" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "5.2" ], "banxico_spei": [ "58a. I.A.e).2" ] } }, { "id": 121, "numero_regla": "8.3.7", "requisito": "8", "seccion": "8.3", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Autenticación fuerte establecida y gestionada", "seccion_titulo_en": "Strong authentication is established and managed", "descripcion_corta": "Nueva contraseña distinta de las últimas cuatro usadas", "descripcion_larga": "Las personas no deben poder establecer una nueva contraseña o frase de paso que sea igual a cualquiera de las cuatro últimas que usaron. Se verifica en la configuración de los sistemas que el historial de contraseñas impida reutilizar las cuatro anteriores. No aplica a cuentas de terminales de punto de venta con acceso a un solo número de tarjeta a la vez.", "remediacion": "1) AWS: PasswordReusePrevention >= 4 en la política de contraseñas de IAM (CIS recomienda 24). 2) Entra ID: las cuentas solo en la nube únicamente impiden repetir la contraseña actual; para cumplir, use un IdP o AD sincronizado con historial >= 4, o autenticación sin contraseña/MFA. 3) Google Workspace: deshabilite 'permitir reutilización de contraseñas'. 4) Sistemas operativos del CDE: pam_pwhistory remember >= 4 (Linux) y 'Enforce password history' >= 4 (Windows). 5) Bases de datos: Cloud SQL passwordValidationPolicy.reuseInterval >= 4 y equivalentes. Evidencia: exportes de configuración de historial por sistema.", "descripcion_corta_en": "New password must differ from the last four used", "descripcion_larga_en": "Individuals must not be able to set a new password or passphrase that matches any of their last four. System configuration is checked to confirm that password history prevents reuse of the previous four. It does not apply to point-of-sale terminal accounts with access to one card number at a time.", "remediacion_en": "1) AWS: PasswordReusePrevention >= 4 in the IAM password policy (CIS recommends 24). 2) Entra ID: cloud-only accounts only prevent reusing the current password; to comply, use an IdP or synced AD with history >= 4, or passwordless/MFA authentication. 3) Google Workspace: disable 'allow password reuse'. 4) CDE operating systems: pam_pwhistory remember >= 4 (Linux) and 'Enforce password history' >= 4 (Windows). 5) Databases: Cloud SQL passwordValidationPolicy.reuseInterval >= 4 and equivalents. Evidence: history configuration exports per system.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 195, "pagina_pdf_es": 208 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Política de contraseñas IAM: PasswordReusePrevention >= 4 (falla si no) [IAM.16]", "Snapshots EC2 Linux: pam_pwhistory remember >= 4 (falla si no)" ], "checks_azure": [ "Entra ID: usuarios solo en la nube con autenticación por contraseña al CDE (alerta: historial no configurable)", "Snapshots de VM: pam_pwhistory remember >= 4 o PasswordHistorySize >= 4 en Windows (falla si no)" ], "checks_gcp": [ "Google Workspace: reutilización de contraseñas deshabilitada (falla si permitida)", "Cloud SQL: passwordValidationPolicy.reuseInterval >= 4 (falla si no)", "Snapshots de Compute Engine Linux: pam_pwhistory remember >= 4 (falla si no)" ], "evidencia": "Exportes de configuración de historial de contraseñas de IAM, IdP, bases de datos y SO.", "evidencia_en": "Password history configuration exports from IAM, IdP, databases and OS.", "limitaciones": "No evalúa aplicaciones propias ni bases de datos sin API de política de contraseñas.", "limitaciones_en": "It does not evaluate custom applications or databases without a password policy API.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.17" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "5.2" ] } }, { "id": 122, "numero_regla": "8.3.8", "requisito": "8", "seccion": "8.3", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Autenticación fuerte establecida y gestionada", "seccion_titulo_en": "Strong authentication is established and managed", "descripcion_corta": "Políticas y procedimientos de autenticación documentados y comunicados a todos los usuarios", "descripcion_larga": "Las políticas y procedimientos de autenticación deben documentarse y comunicarse a todos los usuarios. Deben incluir orientación para elegir factores de autenticación robustos, cómo proteger sus factores, instrucciones de no reutilizar contraseñas anteriores y de cambiar la contraseña ante cualquier sospecha o certeza de compromiso, así como la forma de reportar el incidente. Los usuarios deben conocer estas políticas.", "remediacion": "1) Redacte una política de autenticación que cubra selección de factores robustos, protección de credenciales (no anotarlas, no compartirlas, usar gestor de contraseñas), prohibición de reutilización y cambio inmediato ante sospecha de compromiso con el canal de reporte de incidentes. 2) Publíquela en la intranet y en el portal de inicio de sesión (p. ej. texto de la página de acceso de Entra o del IdP). 3) Incluya el contenido en la capacitación de concientización anual con acuse de recibo. 4) Conserve los registros de distribución y asistencia. Evidencia: política aprobada, registros de distribución, constancias de capacitación y entrevistas con usuarios.", "descripcion_corta_en": "Authentication policies and procedures documented and communicated to all users", "descripcion_larga_en": "Authentication policies and procedures must be documented and communicated to all users. They must include guidance on selecting strong authentication factors, how to protect them, instructions not to reuse previous passwords and to change passwords upon any suspicion or knowledge of compromise, plus how to report the incident. Users must be familiar with these policies.", "remediacion_en": "1) Write an authentication policy covering strong factor selection, credential protection (do not write down or share, use a password manager), no reuse and immediate change upon suspected compromise with the incident reporting channel. 2) Publish it on the intranet and the sign-in portal (e.g., Entra or IdP sign-in page text). 3) Include the content in annual awareness training with acknowledgment. 4) Keep distribution and attendance records. Evidence: approved policy, distribution records, training certificates and user interviews.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 196, "pagina_pdf_es": 209 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Política de autenticación aprobada (generador de políticas de Kyber), registros de distribución y acuses de capacitación cargados por el cliente.", "evidencia_en": "Approved authentication policy (Kyber policy generator), distribution records and training acknowledgments uploaded by the customer.", "limitaciones": "Requisito de proceso; el escaneo no aporta evidencia técnica.", "limitaciones_en": "Process requirement; scanning provides no technical evidence.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.17", "6.3", "5.1" ], "soc2_tsc": [ "CC2.2", "CC1.4" ], "cis_controls_v8": [ "14.3" ] } }, { "id": 123, "numero_regla": "8.3.9", "requisito": "8", "seccion": "8.3", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Autenticación fuerte establecida y gestionada", "seccion_titulo_en": "Strong authentication is established and managed", "descripcion_corta": "Contraseñas como único factor: cambio cada 90 días o análisis dinámico de la postura de la cuenta", "descripcion_larga": "Si las contraseñas o frases de paso son el único factor de autenticación para el acceso de usuarios, debe cumplirse una de dos opciones: cambiarlas al menos cada 90 días, o analizar dinámicamente la postura de seguridad de las cuentas y decidir en tiempo real y de forma automática el acceso a los recursos. No aplica a componentes donde se usa MFA ni a cuentas de terminales de punto de venta con acceso a un solo número de tarjeta a la vez. No aplica a cuentas de clientes de proveedores de servicios, pero sí a las de su personal.", "remediacion": "1) Prefiera eliminar el escenario de un solo factor exigiendo MFA (ver 8.4). 2) Donde persista solo contraseña: AWS IAM MaxPasswordAge <= 90; Entra ID política de expiración de contraseñas <= 90 días por dominio; Google Workspace expiración de contraseña <= 90 días; Linux PASS_MAX_DAYS <= 90 y Windows MaximumPasswordAge <= 90. 3) Alternativa dinámica: Conditional Access basado en riesgo de usuario y de inicio de sesión (Entra ID Protection), Context-Aware Access de Google o señales de riesgo del IdP que bloqueen o exijan remediación automáticamente. 4) Documente qué opción aplica a cada sistema. Evidencia: configuración de expiración o de políticas basadas en riesgo y listado de cuentas de un solo factor.", "descripcion_corta_en": "Password-only authentication: change every 90 days or dynamic account posture analysis", "descripcion_larga_en": "If passwords or passphrases are the only authentication factor for user access, one of two options must be met: change them at least every 90 days, or dynamically analyze the security posture of accounts and automatically determine real-time access to resources. It does not apply to components where MFA is used nor to point-of-sale terminal accounts with access to one card number at a time. It does not apply to service providers' customer accounts but does apply to their personnel accounts.", "remediacion_en": "1) Prefer removing the single-factor scenario by requiring MFA (see 8.4). 2) Where password-only persists: AWS IAM MaxPasswordAge <= 90; Entra ID password expiration policy <= 90 days per domain; Google Workspace password expiration <= 90 days; Linux PASS_MAX_DAYS <= 90 and Windows MaximumPasswordAge <= 90. 3) Dynamic alternative: user- and sign-in-risk Conditional Access (Entra ID Protection), Google Context-Aware Access or IdP risk signals that automatically block or require remediation. 4) Document which option applies to each system. Evidence: expiration or risk-based policy configuration and a list of single-factor accounts.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 197, "pagina_pdf_es": 210 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Usuarios IAM con consola y sin MFA en ausencia de MaxPasswordAge <= 90 (falla) [IAM.17]", "Política de contraseñas IAM: MaxPasswordAge <= 90 (falla si mayor o no definida cuando hay usuarios solo con contraseña)", "Snapshots EC2 Linux: PASS_MAX_DAYS <= 90 en login.defs y en cuentas con contraseña (falla si mayor)" ], "checks_azure": [ "Entra ID: passwordValidityPeriodInDays <= 90 por dominio, o Conditional Access con riesgo de usuario/inicio de sesión para usuarios sin MFA (falla si ninguno)", "Usuarios con acceso al CDE no registrados en MFA (inventario de cuentas de un solo factor)", "Snapshots de VM: expiración de contraseñas <= 90 días (falla si mayor)" ], "checks_gcp": [ "Google Workspace: expiración de contraseña <= 90 días para usuarios sin 2SV obligatorio (falla si no)", "Usuarios sin 2SV inscrito con acceso a proyectos del CDE (inventario de cuentas de un solo factor)", "Snapshots de Compute Engine Linux: PASS_MAX_DAYS <= 90 (falla si mayor)" ], "evidencia": "Inventario generado de cuentas de un solo factor y configuración de expiración o de políticas basadas en riesgo.", "evidencia_en": "Generated inventory of single-factor accounts and expiration or risk-based policy configuration.", "limitaciones": "No puede evaluar la eficacia del análisis dinámico de terceros ni aplicaciones propias con autenticación local.", "limitaciones_en": "It cannot assess the effectiveness of third-party dynamic analysis or custom applications with local authentication.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.17", "8.5" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "5.2" ], "banxico_spei": [ "58a. I.A.e).2" ] } }, { "id": 124, "numero_regla": "8.3.10", "requisito": "8", "seccion": "8.3", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Autenticación fuerte establecida y gestionada", "seccion_titulo_en": "Strong authentication is established and managed", "descripcion_corta": "Proveedores de servicios orientan a clientes sobre cambio de contraseñas cuando son el único factor", "descripcion_larga": "Requisito adicional solo para proveedores de servicios: si las contraseñas o frases de paso son el único factor de autenticación para el acceso de usuarios de sus clientes a datos de tarjetahabiente, el proveedor debe darles orientación para cambiarlas periódicamente e indicar cuándo y en qué circunstancias deben cambiarse. No aplica a cuentas de consumidores que acceden a su propia información de tarjeta de pago. Queda sustituido por el requisito 8.3.10.1 una vez que este entra en vigor.", "remediacion": "1) Publique en el portal o documentación para clientes una guía de manejo de contraseñas que indique la frecuencia recomendada de cambio y las circunstancias que obligan a cambiarla (sospecha de compromiso, salida de personal, incidentes). 2) Muestre la guía en el flujo de alta y en la pantalla de cambio de contraseña. 3) Ofrezca MFA a los clientes para salir del escenario de un solo factor. 4) Conserve versiones y fechas de publicación. Evidencia: guía publicada, capturas del portal y registro de comunicaciones a clientes.", "descripcion_corta_en": "Service providers guide customers on password changes when passwords are the only factor", "descripcion_larga_en": "Additional requirement for service providers only: if passwords or passphrases are the only authentication factor for customer user access to cardholder data, the provider must give customers guidance to change them periodically and indicate when and under what circumstances they must be changed. It does not apply to consumer accounts accessing their own payment card information. It is superseded by requirement 8.3.10.1 once that requirement becomes effective.", "remediacion_en": "1) Publish in the customer portal or documentation a password handling guide stating the recommended change frequency and the circumstances that require a change (suspected compromise, staff departure, incidents). 2) Display the guide in the onboarding flow and on the password change screen. 3) Offer MFA to customers to exit the single-factor scenario. 4) Keep versions and publication dates. Evidence: published guide, portal screenshots and customer communication records.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 199, "pagina_pdf_es": 212 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Guía para clientes publicada y registro de comunicaciones cargados por el cliente.", "evidencia_en": "Published customer guide and communication records uploaded by the customer.", "limitaciones": "Requisito documental; además fue sustituido por 8.3.10.1 a partir del 31 de marzo de 2025.", "limitaciones_en": "Documentation requirement; it was also superseded by 8.3.10.1 from 31 March 2025.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.17", "5.14" ], "soc2_tsc": [ "CC2.3", "CC6.1" ], "cis_controls_v8": [ "5.2" ] } }, { "id": 125, "numero_regla": "8.3.10.1", "requisito": "8", "seccion": "8.3", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Autenticación fuerte establecida y gestionada", "seccion_titulo_en": "Strong authentication is established and managed", "descripcion_corta": "Contraseñas de clientes como único factor: cambio cada 90 días o análisis dinámico (proveedores)", "descripcion_larga": "Requisito adicional solo para proveedores de servicios: si las contraseñas o frases de paso son el único factor de autenticación para el acceso de usuarios de sus clientes, debe cambiarse la contraseña al menos cada 90 días, o bien analizarse dinámicamente la postura de seguridad de las cuentas y determinar de forma automática y en tiempo real el acceso a los recursos. No aplica a cuentas de consumidores que acceden a su propia información de tarjeta de pago. Es obligatorio desde el 31 de marzo de 2025; antes, el proveedor podía cumplir 8.3.10 o este requisito.", "remediacion": "1) Identifique los grupos de usuarios de clientes (Amazon Cognito, Entra External ID/Azure AD B2C, Identity Platform) que se autentican solo con contraseña. 2) Preferentemente habilite o exija MFA para ellos. 3) Si no, aplique expiración de 90 días mediante política del pool o lógica de la aplicación, o habilite autenticación adaptativa basada en riesgo (protección contra amenazas de Cognito en modo de aplicación completa, Conditional Access basado en riesgo para External ID, reCAPTCHA Enterprise/detección de riesgo en Identity Platform) que bloquee o exija verificación adicional. 4) Documente la opción elegida. Evidencia: configuración de pools de usuarios, políticas de expiración o adaptativas y registros de bloqueos por riesgo.", "descripcion_corta_en": "Customer password-only access: change every 90 days or dynamic analysis (service providers)", "descripcion_larga_en": "Additional requirement for service providers only: if passwords or passphrases are the only authentication factor for customer user access, the password must be changed at least every 90 days, or the security posture of the accounts must be dynamically analyzed and real-time access to resources automatically determined. It does not apply to consumer accounts accessing their own payment card information. Mandatory since 31 March 2025; before that, the provider could meet either 8.3.10 or this requirement.", "remediacion_en": "1) Identify customer user populations (Amazon Cognito, Entra External ID/Azure AD B2C, Identity Platform) authenticating with password only. 2) Preferably enable or require MFA for them. 3) Otherwise enforce 90-day expiration via pool policy or application logic, or enable risk-based adaptive authentication (Cognito threat protection in full-function enforcement mode, risk-based Conditional Access for External ID, reCAPTCHA Enterprise/risk detection in Identity Platform) that blocks or requires additional verification. 4) Document the chosen option. Evidence: user pool configuration, expiration or adaptive policies and risk-based block logs.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 200, "pagina_pdf_es": 213 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Cognito user pools: MfaConfiguration = OFF (inventario de pools de un solo factor)", "Cognito user pools sin MFA y sin protección contra amenazas en modo ENFORCED (falla)" ], "checks_azure": [ "Entra External ID/Azure AD B2C: flujos de usuario sin MFA ni Conditional Access basado en riesgo (falla)" ], "checks_gcp": [ "Identity Platform: MFA deshabilitada en tenants de clientes y sin protección basada en riesgo (falla)" ], "evidencia": "Configuración exportada de pools de usuarios de clientes con estado de MFA y protecciones adaptativas.", "evidencia_en": "Exported customer user pool configuration with MFA status and adaptive protections.", "limitaciones": "No puede verificar la expiración de contraseñas implementada en lógica de aplicación propia ni la eficacia del análisis de riesgo.", "limitaciones_en": "It cannot verify password expiration implemented in custom application logic or the effectiveness of risk analysis.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.17", "8.5" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "5.2", "6.3" ] } }, { "id": 126, "numero_regla": "8.3.11", "requisito": "8", "seccion": "8.3", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Autenticación fuerte establecida y gestionada", "seccion_titulo_en": "Strong authentication is established and managed", "descripcion_corta": "Tokens, tarjetas inteligentes o certificados asignados individualmente y no compartidos", "descripcion_larga": "Cuando se utilicen factores de autenticación como tokens de seguridad físicos o lógicos, tarjetas inteligentes o certificados, cada uno debe asignarse a un solo usuario y no compartirse entre varios. Además, deben existir controles físicos o lógicos (por ejemplo, PIN, biométrico o contraseña) que garanticen que solo el usuario previsto pueda usar ese factor para obtener acceso.", "remediacion": "1) Asigne cada dispositivo MFA (llave FIDO2, token TOTP de hardware, aplicación autenticadora) a un solo usuario; en AWS IAM un dispositivo se vincula a un único usuario y no debe registrarse el mismo secreto TOTP en varias cuentas. 2) Para VPN con certificados (AWS Client VPN, Azure VPN Gateway punto a sitio), emita un certificado por usuario o use autenticación federada; no distribuya un certificado de cliente común. 3) Proteja el uso del factor con PIN o biometría (FIDO2 con user verification, tarjetas inteligentes con PIN). 4) Mantenga un inventario de factores asignados y revóquelos al dar de baja. Evidencia: inventario de tokens/certificados por usuario, configuración de verificación del usuario y procedimiento de asignación.", "descripcion_corta_en": "Tokens, smart cards or certificates assigned individually and not shared", "descripcion_larga_en": "When authentication factors such as physical or logical security tokens, smart cards or certificates are used, each must be assigned to a single user and not shared among several. Physical or logical controls (e.g., PIN, biometric or password) must also ensure only the intended user can use that factor to gain access.", "remediacion_en": "1) Assign each MFA device (FIDO2 key, hardware TOTP token, authenticator app) to a single user; in AWS IAM a device binds to a single user and the same TOTP secret must not be enrolled on several accounts. 2) For certificate-based VPN (AWS Client VPN, Azure VPN Gateway point-to-site), issue one certificate per user or use federated authentication; do not distribute a common client certificate. 3) Protect factor use with PIN or biometrics (FIDO2 with user verification, smart cards with PIN). 4) Keep an inventory of assigned factors and revoke them on termination. Evidence: per-user token/certificate inventory, user verification configuration and assignment procedure.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 201, "pagina_pdf_es": 214 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "AWS Client VPN: endpoints con autenticación solo por certificado mutuo sin autenticación de usuario federada/AD (alerta: certificado probablemente compartido)", "IAM: inventario de dispositivos MFA por usuario; dispositivos virtuales sin asignar (alerta)" ], "checks_azure": [ "VPN Gateway punto a sitio: autenticación solo por certificado sin Entra ID (alerta)", "Entra ID: métodos FIDO2 con enforceAttestation / restricciones de llaves y autenticación basada en certificados con vinculación por usuario (alerta si no)" ], "checks_gcp": [ "Llaves de cuentas de servicio usadas por humanos como credencial compartida (alerta)", "Google Workspace: inventario de llaves de seguridad por usuario (alerta si sin inscripción individual)" ], "evidencia": "Inventario de factores de autenticación por usuario y configuración de verificación de usuario; el cliente aporta el procedimiento de asignación.", "evidencia_en": "Per-user authentication factor inventory and user verification configuration; the customer provides the assignment procedure.", "limitaciones": "No puede detectar que un token físico o un secreto TOTP sea usado por varias personas ni verificar controles físicos.", "limitaciones_en": "It cannot detect that a physical token or TOTP secret is used by several people or verify physical controls.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.17", "8.5" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "5.2", "6.5" ] } }, { "id": 127, "numero_regla": "8.4.1", "requisito": "8", "seccion": "8.4", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Autenticación multifactor (MFA) para el acceso al CDE", "seccion_titulo_en": "Multi-factor authentication (MFA) secures access into the CDE", "descripcion_corta": "MFA para todo acceso administrativo sin consola al CDE", "descripcion_larga": "Debe implementarse autenticación multifactor (MFA) para todo acceso sin consola al CDE realizado por personal con acceso administrativo. Aplica a todo el personal con privilegios elevados que accede al CDE mediante una conexión lógica a través de una interfaz de red, en lugar de una conexión física directa. Usar dos veces el mismo tipo de factor no se considera MFA.", "remediacion": "1) AWS: habilite MFA en la cuenta root (de hardware preferentemente) y en todo usuario IAM con consola; prefiera IAM Identity Center con MFA obligatorio en cada inicio de sesión para roles administrativos. 2) Acceso a instancias: use Session Manager o EC2 Instance Connect detrás de un IdP con MFA en lugar de SSH/RDP expuestos; no permita 22/3389 desde Internet. 3) Azure: Conditional Access que exija MFA (idealmente resistente al phishing) a roles de directorio privilegiados y a la aplicación Microsoft Azure Management; PIM con MFA en la activación; Bastion o JIT para VMs. 4) GCP: 2SV obligatorio para administradores en Workspace/Cloud Identity, IAP para SSH/RDP y OS Login con 2FA. 5) Bases de datos y equipos de red del CDE: autenticación a través de bastión o PAM con MFA. Evidencia: configuraciones de MFA, reporte de usuarios privilegiados con su estado de MFA y observación de inicios de sesión.", "descripcion_corta_en": "MFA for all non-console administrative access into the CDE", "descripcion_larga_en": "Multi-factor authentication (MFA) must be implemented for all non-console access into the CDE by personnel with administrative access. It applies to all personnel with elevated privileges accessing the CDE over a logical connection through a network interface rather than a direct physical connection. Using the same factor type twice is not MFA.", "remediacion_en": "1) AWS: enable MFA on the root user (preferably hardware) and on every IAM user with console access; prefer IAM Identity Center with MFA required at every sign-in for administrative roles. 2) Instance access: use Session Manager or EC2 Instance Connect behind an MFA-enforcing IdP instead of exposed SSH/RDP; do not allow 22/3389 from the Internet. 3) Azure: Conditional Access requiring MFA (ideally phishing-resistant) for privileged directory roles and the Microsoft Azure Management app; PIM with MFA on activation; Bastion or JIT for VMs. 4) GCP: mandatory 2SV for admins in Workspace/Cloud Identity, IAP for SSH/RDP and OS Login with 2FA. 5) CDE databases and network devices: authenticate through a bastion or PAM with MFA. Evidence: MFA configurations, privileged user report with MFA status and observed logins.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 202, "pagina_pdf_es": 215 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "MFA habilitado en la cuenta root (falla si no) [IAM.9]; MFA de hardware en root [IAM.6]", "Usuarios IAM con contraseña de consola sin MFA (falla) [IAM.5] [IAM.19]", "IAM Identity Center: MFA requerido en cada inicio de sesión (falla si 'nunca' o solo sensible al contexto)", "Security groups con 0.0.0.0/0 o ::/0 en puertos 22/3389 (falla si existe) [EC2.19]", "Filtro de métricas y alarma para inicios de sesión de consola sin MFA (falla si no existe) [CloudWatch.3]" ], "checks_azure": [ "Conditional Access: política que exige MFA a roles de directorio administrativos (falla si no existe o con exclusiones no documentadas)", "Conditional Access: MFA para la aplicación Microsoft Azure Management / Windows Azure Service Management API (falla si no)", "Cuentas con rol Owner o Contributor sobre suscripciones del CDE sin MFA registrado (falla)", "NSG con reglas de entrada desde Internet a 22/3389 (falla si existe)" ], "checks_gcp": [ "Google Workspace/Cloud Identity: 2SV obligatorio para super administradores y administradores (falla si no)", "Compute Engine: metadato enable-oslogin-2fa = TRUE en proyectos del CDE (falla si no)", "Reglas de firewall VPC con 0.0.0.0/0 a 22/3389 (falla si existe; usar IAP 35.235.240.0/20)" ], "evidencia": "Reporte generado de identidades privilegiadas con estado de MFA y configuraciones de Identity Center, Conditional Access y 2SV.", "evidencia_en": "Generated report of privileged identities with MFA status and Identity Center, Conditional Access and 2SV configurations.", "limitaciones": "No observa inicios de sesión reales ni cubre MFA en equipos de red, bases de datos o aplicaciones fuera de las APIs de identidad de la nube.", "limitaciones_en": "It does not observe real logins or cover MFA on network devices, databases or applications outside the cloud identity APIs.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.5", "8.2", "5.17" ], "soc2_tsc": [ "CC6.1", "CC6.6" ], "cis_controls_v8": [ "6.5" ], "banxico_spei": [ "58a. I.A.f).8" ] }, "mapeo_ucf": [ { "clave": "UCF-IAM-004", "relacion": "partial", "cobertura_pct": 60, "nota_es": "PCI lo exige solo dentro del CDE.", "nota_en": "PCI requires it only within the CDE." } ] }, { "id": 128, "numero_regla": "8.4.2", "requisito": "8", "seccion": "8.4", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Autenticación multifactor (MFA) para el acceso al CDE", "seccion_titulo_en": "Multi-factor authentication (MFA) secures access into the CDE", "descripcion_corta": "MFA para todo acceso sin consola al CDE", "descripcion_larga": "Debe implementarse MFA para todo acceso sin consola al CDE, no solo el administrativo. No aplica a cuentas de aplicación o de sistema que ejecutan funciones automatizadas, a cuentas de terminales de punto de venta con acceso a un solo número de tarjeta a la vez, ni a cuentas que se autentican únicamente con factores resistentes al phishing. El MFA puede aplicarse a nivel de red o de sistema/aplicación (no se requiere en ambos), cubre nube, sistemas alojados, aplicaciones web y endpoints, y es independiente del MFA de acceso remoto de 8.4.3, por lo que ambos pueden requerirse. Es obligatorio desde el 31 de marzo de 2025.", "remediacion": "1) Lleve todo el acceso humano al CDE a través de un IdP con MFA: IAM Identity Center/federación SAML en AWS, Conditional Access en Entra ID y 2SV obligatorio en Google. 2) Elimine usuarios IAM con consola sin MFA y llaves de acceso de larga duración para personas (use credenciales temporales de Identity Center o aws-vault con MFA). 3) Exija MFA para el acceso a aplicaciones web internas del CDE (ALB con autenticación OIDC, Entra Application Proxy, IAP). 4) Para bases de datos e instancias, use Session Manager, IAP o Bastion detrás de MFA. 5) Documente las cuentas exentas (de aplicación/automatizadas o con factores resistentes al phishing). Evidencia: políticas de MFA, reporte de cobertura por usuario y observación de inicios de sesión.", "descripcion_corta_en": "MFA for all non-console access into the CDE", "descripcion_larga_en": "MFA must be implemented for all non-console access into the CDE, not only administrative access. It does not apply to application or system accounts performing automated functions, to point-of-sale terminal accounts with access to one card number at a time, nor to accounts authenticated solely with phishing-resistant factors. MFA may be applied at the network or the system/application level (not both), covers cloud, hosted systems, web applications and endpoints, and is separate from the remote access MFA of 8.4.3, so both may be required. Mandatory since 31 March 2025.", "remediacion_en": "1) Route all human access to the CDE through an MFA-enforcing IdP: IAM Identity Center/SAML federation in AWS, Conditional Access in Entra ID and mandatory 2SV in Google. 2) Remove console IAM users without MFA and long-lived access keys for people (use Identity Center temporary credentials or aws-vault with MFA). 3) Require MFA for internal CDE web applications (ALB with OIDC authentication, Entra Application Proxy, IAP). 4) For databases and instances, use Session Manager, IAP or Bastion behind MFA. 5) Document exempt accounts (application/automated or phishing-resistant factors). Evidence: MFA policies, per-user coverage report and observed logins.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 203, "pagina_pdf_es": 216 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Usuarios IAM con contraseña de consola sin MFA (falla) [IAM.5] [IAM.19]", "Llaves de acceso de usuarios IAM humanos usadas sin condición aws:MultiFactorAuthPresent (alerta)", "IAM Identity Center: MFA obligatorio y bloqueo de inicio de sesión sin dispositivo registrado (falla si no)", "ALB de aplicaciones internas del CDE sin acción authenticate-oidc/cognito ni IdP con MFA (alerta)" ], "checks_azure": [ "Conditional Access: política que exige MFA a todos los usuarios para todas las aplicaciones de nube (falla si no existe)", "Usuarios con acceso a suscripciones/grupos de recursos del CDE sin método MFA registrado (falla)", "Security Defaults o Conditional Access habilitados en el inquilino (falla si ninguno)" ], "checks_gcp": [ "Google Workspace/Cloud Identity: 2SV obligatorio para todas las unidades organizativas con acceso al CDE (falla si no)", "IAP habilitado para aplicaciones y SSH del CDE con 2SV aplicado (alerta si no)", "Usuarios con roles en proyectos del CDE sin 2SV inscrito (falla)" ], "evidencia": "Reporte generado de cobertura de MFA por usuario con acceso al CDE y configuraciones de políticas de MFA.", "evidencia_en": "Generated MFA coverage report per user with CDE access and MFA policy configurations.", "limitaciones": "No determina qué cuentas usan exclusivamente factores resistentes al phishing en todos los casos ni cubre MFA en aplicaciones propias o bases de datos con autenticación local.", "limitaciones_en": "It cannot always determine which accounts use phishing-resistant factors exclusively, nor cover MFA in custom applications or databases with local authentication.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.5", "5.17" ], "soc2_tsc": [ "CC6.1", "CC6.6" ], "cis_controls_v8": [ "6.3", "6.5" ], "banxico_spei": [ "58a. I.A.e).2", "58a. I.C.d)" ] }, "mapeo_ucf": [ { "clave": "UCF-IAM-004", "relacion": "partial", "cobertura_pct": 60, "nota_es": "PCI lo exige solo dentro del CDE.", "nota_en": "PCI requires it only within the CDE." } ] }, { "id": 129, "numero_regla": "8.4.3", "requisito": "8", "seccion": "8.4", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Autenticación multifactor (MFA) para el acceso al CDE", "seccion_titulo_en": "Multi-factor authentication (MFA) secures access into the CDE", "descripcion_corta": "MFA para todo acceso remoto desde fuera de la red que pueda acceder o afectar al CDE", "descripcion_larga": "Debe implementarse MFA para todo acceso remoto que se origine fuera de la red de la entidad y que pueda llegar al CDE o afectarlo. Aplica a todas las cuentas que pueden conectarse remotamente, incluidos usuarios, administradores y terceros (proveedores, prestadores de servicios y clientes). Si el acceso remoto llega a un segmento correctamente aislado del CDE, no se requiere MFA, aunque se recomienda; aplica a todo tipo de componente, incluidos nube, sistemas alojados y acceso web a aplicaciones.", "remediacion": "1) AWS Client VPN: use autenticación federada (SAML) con IdP que exija MFA o Active Directory con MFA; evite solo certificado. 2) Azure VPN Gateway punto a sitio con autenticación de Entra ID y Conditional Access con MFA; Azure Virtual Desktop y Bastion protegidos con Conditional Access. 3) GCP: IAP con acceso según contexto y 2SV obligatorio en lugar de VPN o IP públicas con SSH/RDP. 4) Considere que la consola web y las APIs de las nubes son acceso remoto desde Internet: exija MFA en el IdP para todos los usuarios con acceso al CDE. 5) Incluya terceros y proveedores en el alcance de las políticas. Evidencia: configuración de servidores de acceso remoto y del IdP, y observación de conexiones remotas.", "descripcion_corta_en": "MFA for all remote access from outside the network that could access or impact the CDE", "descripcion_larga_en": "MFA must be implemented for all remote access originating from outside the entity's network that could reach or impact the CDE. It applies to all accounts able to connect remotely, including users, administrators and third parties (vendors, suppliers, service providers and customers). If remote access lands in a segment properly isolated from the CDE, MFA is not required, although it is recommended; it applies to all component types, including cloud, hosted systems and web access to applications.", "remediacion_en": "1) AWS Client VPN: use federated (SAML) authentication with an MFA-enforcing IdP or Active Directory with MFA; avoid certificate-only. 2) Azure VPN Gateway point-to-site with Entra ID authentication and MFA Conditional Access; Azure Virtual Desktop and Bastion protected by Conditional Access. 3) GCP: IAP with context-aware access and mandatory 2SV instead of VPNs or public IPs with SSH/RDP. 4) Treat cloud web consoles and APIs as remote access from the Internet: require MFA at the IdP for all users with CDE access. 5) Include third parties and vendors in policy scope. Evidence: remote access server and IdP configuration, and observed remote connections.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 206, "pagina_pdf_es": 218 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "AWS Client VPN: endpoints con autenticación solo por certificado mutuo sin SAML/AD con MFA (falla)", "Security groups con 0.0.0.0/0 o ::/0 en puertos 22/3389 u otros puertos administrativos (falla si existe) [EC2.19]", "WorkSpaces: directorios sin MFA (RADIUS) habilitado (falla si se usan para acceder al CDE)", "Usuarios IAM con consola sin MFA (falla) [IAM.5]" ], "checks_azure": [ "VPN Gateway punto a sitio: autenticación sin Entra ID/MFA (falla)", "Conditional Access: MFA para Azure Virtual Desktop, VPN y accesos desde fuera de ubicaciones de confianza (falla si no)", "VMs del CDE con IP pública y NSG abierto a Internet en 22/3389 (falla)" ], "checks_gcp": [ "Reglas de firewall VPC con 0.0.0.0/0 a puertos administrativos (falla si existe)", "IAP con niveles de acceso (Access Context Manager) para recursos del CDE (alerta si no)", "Google Workspace: 2SV obligatorio para usuarios con acceso remoto al CDE (falla si no)" ], "evidencia": "Configuración de servidores de acceso remoto (Client VPN, VPN Gateway, IAP, WorkSpaces/AVD) y del IdP con evidencia de MFA.", "evidencia_en": "Remote access server configuration (Client VPN, VPN Gateway, IAP, WorkSpaces/AVD) and IdP configuration evidencing MFA.", "limitaciones": "No cubre VPN o soluciones de acceso remoto de terceros fuera de la nube ni puede confirmar la segmentación que exime del requisito sin pruebas adicionales.", "limitaciones_en": "It does not cover third-party or non-cloud remote access solutions and cannot confirm the segmentation that exempts the requirement without additional testing.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.5", "6.7", "5.17" ], "soc2_tsc": [ "CC6.1", "CC6.6" ], "cis_controls_v8": [ "6.4", "12.7" ], "banxico_spei": [ "58a. I.A.g).6" ] } }, { "id": 130, "numero_regla": "8.5.1", "requisito": "8", "seccion": "8.5", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Sistemas MFA configurados para evitar su uso indebido", "seccion_titulo_en": "MFA systems are configured to prevent misuse", "descripcion_corta": "Sistemas MFA resistentes a repetición, sin evasión y con éxito de todos los factores", "descripcion_larga": "Los sistemas MFA deben implementarse de forma que no sean susceptibles a ataques de repetición y no puedan ser evadidos por ningún usuario, incluidos los administradores, salvo excepciones documentadas y autorizadas por la dirección por un periodo limitado. Deben usarse al menos dos tipos distintos de factores y todos deben validarse con éxito antes de otorgar el acceso. Es obligatorio desde el 31 de marzo de 2025.", "remediacion": "1) Use métodos resistentes a repetición: FIDO2/WebAuthn, TOTP, notificaciones push con coincidencia de número; evite códigos estáticos y limite SMS/voz. 2) Elimine evasiones: revise exclusiones de Conditional Access (usuarios, grupos, ubicaciones de confianza), cuentas con 'MFA por usuario' deshabilitado, la opción de IAM Identity Center que permite iniciar sesión sin dispositivo MFA registrado y unidades organizativas de Google sin 2SV obligatorio. 3) Registre cada excepción con justificación, aprobación de la dirección y fecha de expiración, y aplíquela con grupos de exclusión temporales (Entra PIM o Access Packages con caducidad). 4) Configure el IdP para que la falla de cualquier factor no revele cuál falló y que el acceso solo se conceda tras validar todos. 5) Conserve documentación del proveedor sobre protección contra repetición. Evidencia: configuración de métodos MFA, inventario de exclusiones con aprobaciones y observación de inicios de sesión.", "descripcion_corta_en": "MFA systems resist replay, cannot be bypassed and require success of all factors", "descripcion_larga_en": "MFA systems must be implemented so that they are not susceptible to replay attacks and cannot be bypassed by any user, including administrators, except for exceptions documented and authorized by management for a limited time. At least two different factor types must be used and all must succeed before access is granted. Mandatory since 31 March 2025.", "remediacion_en": "1) Use replay-resistant methods: FIDO2/WebAuthn, TOTP, push notifications with number matching; avoid static codes and limit SMS/voice. 2) Remove bypasses: review Conditional Access exclusions (users, groups, trusted locations), accounts with per-user MFA disabled, the IAM Identity Center option allowing sign-in without a registered MFA device and Google OUs without mandatory 2SV. 3) Record each exception with justification, management approval and expiry date, and enforce it with temporary exclusion groups (Entra PIM or Access Packages with expiry). 4) Configure the IdP so that failure of any factor does not reveal which one failed and access is granted only after validating all. 5) Keep vendor documentation on replay protection. Evidence: MFA method configuration, exclusions inventory with approvals and observed logins.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 208, "pagina_pdf_es": 220 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "IAM Identity Center: opción 'permitir iniciar sesión' sin dispositivo MFA registrado (falla si habilitada)", "Políticas IAM que permiten acciones sensibles sin condición aws:MultiFactorAuthPresent para usuarios IAM humanos (alerta)", "Inicios de sesión de consola sin MFA en CloudTrail (MFAUsed = No) (falla si existen) [CloudWatch.3]" ], "checks_azure": [ "Conditional Access: usuarios, grupos o ubicaciones excluidos de políticas de MFA (inventario; falla si sin expiración documentada)", "Métodos de autenticación: SMS/voz habilitados para administradores (alerta); coincidencia de número en Authenticator habilitada (falla si no)", "Ubicaciones con nombre marcadas como de confianza que omiten MFA (alerta)" ], "checks_gcp": [ "Google Workspace: unidades organizativas o grupos de excepción sin 2SV obligatorio (inventario; falla si sin expiración)", "Métodos 2SV permitidos: solo llaves de seguridad para administradores o exclusión de SMS (alerta si no)", "Periodo de gracia de inscripción de 2SV activo para usuarios con acceso al CDE (alerta)" ], "evidencia": "Inventario generado de exclusiones y métodos MFA por IdP; el cliente aporta aprobaciones de excepciones y documentación del proveedor sobre protección contra repetición.", "evidencia_en": "Generated inventory of exclusions and MFA methods per IdP; the customer provides exception approvals and vendor documentation on replay protection.", "limitaciones": "No puede probar la resistencia a repetición ni que todos los factores se validen antes del acceso en IdP de terceros o aplicaciones propias; solo evalúa configuración.", "limitaciones_en": "It cannot test replay resistance or that all factors are validated before access in third-party IdPs or custom applications; it only evaluates configuration.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.5", "5.17" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "6.3", "6.4", "6.5" ] } }, { "id": 131, "numero_regla": "8.6.1", "requisito": "8", "seccion": "8.6", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Cuentas de aplicación y sistema y sus factores gestionados estrictamente", "seccion_titulo_en": "Application and system accounts and their factors are strictly managed", "descripcion_corta": "Uso interactivo de cuentas de sistema o aplicación solo por excepción y atribuible a una persona", "descripcion_larga": "Si las cuentas de sistemas o aplicaciones pueden usarse para iniciar sesión de forma interactiva, debe impedirse ese uso salvo en circunstancias excepcionales, limitarlo al tiempo necesario, documentar la justificación de negocio y contar con aprobación explícita de la dirección. Antes de conceder el acceso debe confirmarse la identidad de la persona y cada acción realizada debe poder atribuirse a un usuario individual. Es obligatorio desde el 31 de marzo de 2025.", "remediacion": "1) Inventaríe cuentas de sistema y aplicación: usuarios IAM técnicos, roles de servicio, cuentas de servicio de GCP, service principals e identidades administradas de Azure, y cuentas locales de SO y bases de datos. 2) Quite la capacidad interactiva: usuarios IAM técnicos sin perfil de inicio de sesión (sin contraseña de consola), cuentas de SO con shell /sbin/nologin y sin contraseña, cuentas de servicio de Entra bloqueadas para inicio de sesión interactivo por Conditional Access, y prefiera roles/identidades administradas sin credenciales. 3) Restrinja la suplantación (iam.serviceAccountTokenCreator, sts:AssumeRole sobre roles de servicio) a grupos aprobados y regístrela. 4) Para usos excepcionales, use check-out en bóveda/PAM con aprobación, tiempo limitado y vinculación de la persona en las bitácoras. Evidencia: inventario de cuentas de sistema, configuraciones que impiden el uso interactivo y registro de excepciones.", "descripcion_corta_en": "Interactive use of system or application accounts only by exception and attributable to an individual", "descripcion_larga_en": "If system or application accounts can be used for interactive login, such use must be prevented except in exceptional circumstances, limited to the time needed, backed by documented business justification and explicitly approved by management. The person's identity must be confirmed before access is granted and every action taken must be attributable to an individual user. Mandatory since 31 March 2025.", "remediacion_en": "1) Inventory system and application accounts: technical IAM users, service roles, GCP service accounts, Azure service principals and managed identities, and local OS and database accounts. 2) Remove interactive capability: technical IAM users without a login profile (no console password), OS accounts with /sbin/nologin shell and no password, Entra service accounts blocked from interactive sign-in via Conditional Access, and prefer roles/managed identities without credentials. 3) Restrict impersonation (iam.serviceAccountTokenCreator, sts:AssumeRole on service roles) to approved groups and log it. 4) For exceptional use, use vault/PAM check-out with approval, time limits and the individual linked in the logs. Evidence: system account inventory, configurations preventing interactive use and exceptions register.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 210, "pagina_pdf_es": 222 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Usuarios IAM técnicos (con llaves de acceso programáticas) que además tienen perfil de inicio de sesión de consola (falla)", "Políticas de confianza de roles de servicio que permiten AssumeRole a usuarios humanos sin restricción (alerta)", "Snapshots EC2: cuentas de servicio en /etc/passwd con shell interactivo y contraseña definida en /etc/shadow (falla)" ], "checks_azure": [ "Entra ID: cuentas de usuario usadas como cuentas de servicio con inicios de sesión interactivos en sign-in logs (falla)", "Service principals con credenciales de contraseña en lugar de identidades administradas (alerta)", "Snapshots de VM: cuentas de servicio locales con shell interactivo o derecho de inicio de sesión local/RDP (falla)" ], "checks_gcp": [ "IAM: usuarios con roles/iam.serviceAccountUser o serviceAccountTokenCreator a nivel proyecto (alerta)", "Llaves de cuentas de servicio administradas por el usuario existentes (alerta; política iam.disableServiceAccountKeyCreation)", "Snapshots de Compute Engine: cuentas de servicio locales con shell interactivo y contraseña (falla)" ], "evidencia": "Inventario generado de cuentas de sistema/aplicación con capacidad interactiva; el cliente aporta justificaciones y aprobaciones de uso excepcional.", "evidencia_en": "Generated inventory of system/application accounts with interactive capability; the customer provides justifications and approvals for exceptional use.", "limitaciones": "No puede distinguir con certeza cuentas de usuario usadas como cuentas de servicio sin etiquetado, ni verificar la aprobación de la dirección.", "limitaciones_en": "It cannot reliably distinguish user accounts used as service accounts without tagging, nor verify management approval.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.16", "5.17", "8.2" ], "soc2_tsc": [ "CC6.1", "CC6.2", "CC6.3" ], "cis_controls_v8": [ "5.5", "5.4" ] } }, { "id": 132, "numero_regla": "8.6.2", "requisito": "8", "seccion": "8.6", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Cuentas de aplicación y sistema y sus factores gestionados estrictamente", "seccion_titulo_en": "Application and system accounts and their factors are strictly managed", "descripcion_corta": "Contraseñas de cuentas de sistema o aplicación con inicio interactivo no embebidas en código ni archivos", "descripcion_larga": "Las contraseñas o frases de paso de cuentas de aplicación y de sistema que puedan usarse para iniciar sesión de forma interactiva no deben estar codificadas en scripts, archivos de configuración o propiedades, ni en código fuente a la medida o personalizado. Las contraseñas almacenadas deben cifrarse conforme al requisito 8.3.2. Es obligatorio desde el 31 de marzo de 2025.", "remediacion": "1) Mueva todas las credenciales a un almacén administrado: AWS Secrets Manager o SSM Parameter Store SecureString, Azure Key Vault (referencias de Key Vault en App Service/Functions) y Google Secret Manager (secretos montados en Cloud Run/Functions). 2) Elimine secretos en texto claro de variables de entorno de Lambda, definiciones de tareas ECS, proyectos CodeBuild, user data de EC2, scripts de inicio de GCE, configuración de aplicaciones de Azure y archivos en imágenes y discos. 3) Use identidades sin secreto donde sea posible (roles de IAM, identidades administradas, Workload Identity). 4) Agregue escaneo de secretos en el pipeline de CI/CD y en los repositorios, y rote cualquier secreto expuesto. 5) Documente en el procedimiento de desarrollo la prohibición de credenciales embebidas. Evidencia: resultado de escaneo de secretos de Kyber sin hallazgos, procedimiento de desarrollo y uso de almacenes de secretos.", "descripcion_corta_en": "Passwords of interactive-capable system or application accounts not hard-coded in code or files", "descripcion_larga_en": "Passwords or passphrases of application and system accounts that can be used for interactive login must not be hard-coded in scripts, configuration or property files, or bespoke and custom source code. Stored passwords must be encrypted per requirement 8.3.2. Mandatory since 31 March 2025.", "remediacion_en": "1) Move all credentials to a managed store: AWS Secrets Manager or SSM Parameter Store SecureString, Azure Key Vault (Key Vault references in App Service/Functions) and Google Secret Manager (secrets mounted in Cloud Run/Functions). 2) Remove cleartext secrets from Lambda environment variables, ECS task definitions, CodeBuild projects, EC2 user data, GCE startup scripts, Azure app settings and files in images and disks. 3) Use secretless identities where possible (IAM roles, managed identities, Workload Identity). 4) Add secret scanning to the CI/CD pipeline and repositories, and rotate any exposed secret. 5) Document the prohibition of embedded credentials in the development procedure. Evidence: Kyber secret scan with no findings, development procedure and use of secret stores.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 211, "pagina_pdf_es": 223 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Kyber: secretos en texto claro en variables de entorno de Lambda (falla si existen)", "ECS: secretos pasados como variables de entorno en definiciones de tareas en lugar de secrets/valueFrom (falla) [ECS.8]", "CodeBuild: variables de entorno con credenciales en texto claro (falla) [CodeBuild.2]", "Kyber: contraseñas en archivos de configuración, scripts o user data de EC2 detectadas en snapshots (falla)" ], "checks_azure": [ "App Service/Functions: app settings y connection strings con secretos en texto claro en lugar de referencias de Key Vault (falla)", "Kyber: secretos en archivos de configuración detectados en snapshots de discos de VM (falla)", "Container Apps/AKS: variables de entorno con secretos en texto claro (falla)" ], "checks_gcp": [ "Cloud Run/Cloud Functions: variables de entorno con secretos en texto claro en lugar de referencias a Secret Manager (falla)", "Compute Engine: metadatos startup-script o atributos con credenciales (falla)", "Kyber: secretos en archivos detectados en snapshots de discos persistentes (falla)" ], "evidencia": "Reporte de escaneo de secretos de Kyber (variables de entorno, metadatos, snapshots) y procedimiento de desarrollo seguro del cliente.", "evidencia_en": "Kyber secret scan report (environment variables, metadata, snapshots) and the customer's secure development procedure.", "limitaciones": "No escanea repositorios de código fuera de la nube del cliente ni determina con certeza si la credencial detectada pertenece a una cuenta con inicio interactivo.", "limitaciones_en": "It does not scan code repositories outside the customer's cloud nor reliably determine whether a detected credential belongs to an interactive-capable account.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.17", "8.4", "8.28" ], "soc2_tsc": [ "CC6.1", "CC8.1" ], "cis_controls_v8": [ "16.1", "5.5", "3.11" ] } }, { "id": 133, "numero_regla": "8.6.3", "requisito": "8", "seccion": "8.6", "categoria": "Requisito 8: Identificar a los usuarios y autenticar el acceso a los componentes del sistema", "categoria_en": "Requirement 8: Identify Users and Authenticate Access to System Components", "seccion_titulo": "Cuentas de aplicación y sistema y sus factores gestionados estrictamente", "seccion_titulo_en": "Application and system accounts and their factors are strictly managed", "descripcion_corta": "Contraseñas de cuentas de sistema o aplicación rotadas según análisis de riesgos y con complejidad suficiente", "descripcion_larga": "Las contraseñas o frases de paso de cualquier cuenta de aplicación o de sistema deben protegerse contra el uso indebido: cambiarse periódicamente con la frecuencia definida en el análisis de riesgos específico de la entidad (realizado conforme a 12.3.1) y ante sospecha o confirmación de compromiso. Además, deben tener una complejidad acorde con la frecuencia de cambio, más rigurosa cuanto menos frecuente sea la rotación. Es obligatorio desde el 31 de marzo de 2025.", "remediacion": "1) Realice y documente un análisis de riesgos específico (12.3.1) que defina frecuencia de rotación y complejidad para credenciales de aplicación y sistema (como referencia, rotación anual y 15 o más caracteres con mayúsculas, minúsculas, números y especiales). 2) Habilite rotación automática: AWS Secrets Manager con calendario de rotación y RDS ManageMasterUserPassword; Azure Key Vault con políticas de rotación y fechas de expiración; Google Secret Manager con rotation schedule. 3) Rote llaves de acceso de IAM y llaves de cuentas de servicio de GCP en 90 días o menos, o elimínelas en favor de roles/identidades administradas/Workload Identity. 4) Defina un procedimiento de rotación inmediata ante sospecha de compromiso. Evidencia: análisis de riesgos, configuración de rotación y antigüedad de secretos y llaves.", "descripcion_corta_en": "System or application account passwords rotated per risk analysis and sufficiently complex", "descripcion_larga_en": "Passwords or passphrases for any application or system account must be protected against misuse: changed periodically at the frequency defined in the entity's targeted risk analysis (performed per 12.3.1) and upon suspected or confirmed compromise. They must also have complexity appropriate to the change frequency, stricter the less frequently they are rotated. Mandatory since 31 March 2025.", "remediacion_en": "1) Perform and document a targeted risk analysis (12.3.1) defining rotation frequency and complexity for application and system credentials (as a reference, yearly rotation and 15+ characters with upper and lower case, numbers and special characters). 2) Enable automatic rotation: AWS Secrets Manager with a rotation schedule and RDS ManageMasterUserPassword; Azure Key Vault with rotation policies and expiration dates; Google Secret Manager with a rotation schedule. 3) Rotate IAM access keys and GCP service account keys within 90 days or remove them in favor of roles/managed identities/Workload Identity. 4) Define an immediate rotation procedure upon suspected compromise. Evidence: risk analysis, rotation configuration and age of secrets and keys.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 212, "pagina_pdf_es": 224 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Secrets Manager: rotación automática habilitada (falla si no) [SecretsManager.1]", "Secrets Manager: secretos rotados dentro del número de días definido (falla si no) [SecretsManager.4]", "Llaves de acceso de usuarios IAM con antigüedad > 90 días (falla) [IAM.3]", "RDS: contraseña maestra no administrada por Secrets Manager (ManageMasterUserPassword = false) (alerta)" ], "checks_azure": [ "Key Vault: secretos sin fecha de expiración (falla) y sin política de rotación (alerta)", "Service principals con secretos de cliente con vigencia > 1 año o vencidos sin rotar (falla)", "Azure SQL/servidores con autenticación por contraseña de administrador sin rotación documentada (alerta)" ], "checks_gcp": [ "Secret Manager: secretos sin rotation schedule (alerta)", "Llaves de cuentas de servicio administradas por el usuario con antigüedad > 90 días (falla)", "Cloud SQL: contraseñas de usuarios de base de datos sin política de complejidad (falla si passwordValidationPolicy deshabilitada)" ], "evidencia": "Reporte generado de antigüedad y rotación de secretos y llaves; el cliente aporta el análisis de riesgos específico (12.3.1).", "evidencia_en": "Generated report of secret and key age and rotation; the customer provides the targeted risk analysis (12.3.1).", "limitaciones": "No evalúa la complejidad real de los secretos almacenados ni contraseñas de cuentas de sistema fuera de los almacenes administrados; la frecuencia adecuada depende del análisis de riesgos.", "limitaciones_en": "It does not evaluate the actual complexity of stored secrets or system account passwords outside managed stores; the appropriate frequency depends on the risk analysis.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.17", "8.24", "8.5" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "5.2", "5.5", "3.11" ] } }, { "id": 134, "numero_regla": "9.1.1", "requisito": "9", "seccion": "9.1", "categoria": "Requisito 9: Restringir el acceso físico a los datos de tarjetahabiente", "categoria_en": "Requirement 9: Restrict Physical Access to Cardholder Data", "seccion_titulo": "Procesos y mecanismos de acceso físico definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for physical access are defined and understood", "descripcion_corta": "Políticas y procedimientos operativos de seguridad física (Requisito 9) gestionados", "descripcion_larga": "Las políticas de seguridad y los procedimientos operativos que se definen para el Requisito 9 (restricción del acceso físico a los datos del titular de la tarjeta) deben estar documentados, mantenerse actualizados, estar en uso y ser conocidos por todas las partes involucradas. El objetivo es que las expectativas y la supervisión sobre la seguridad física se apliquen de forma repetible y consistente con la intención de la dirección.", "remediacion": "1) Redacte una política de seguridad física que distinga lo heredado del proveedor de nube (centros de datos) de lo que sigue siendo responsabilidad del cliente (oficinas, medios, papel, dispositivos POI). 2) Referencie la matriz de responsabilidad compartida PCI DSS de AWS/Azure/GCP y descargue sus AOC vigentes (AWS Artifact, Service Trust Portal, Compliance Reports Manager). 3) Defina procedimientos para medios, destrucción y respaldos fuera de línea. 4) Revise y apruebe los documentos al menos una vez al año y tras cambios relevantes. 5) Comuníquelos al personal afectado y conserve acuses de lectura. El QSA pedirá la política con control de versiones, evidencia de aprobación y de difusión.", "descripcion_corta_en": "Physical security policies and operational procedures (Requirement 9) are managed", "descripcion_larga_en": "Security policies and operational procedures defined for Requirement 9 (restricting physical access to cardholder data) must be documented, kept current, actively used and known to everyone affected. The intent is that expectations and oversight for physical security are applied repeatably and consistently with management's intent.", "remediacion_en": "1) Write a physical security policy that separates what is inherited from the cloud provider (data centers) from what remains the customer's responsibility (offices, media, paper, POI devices). 2) Reference the AWS/Azure/GCP PCI DSS shared responsibility matrix and download their current AOCs (AWS Artifact, Service Trust Portal, Compliance Reports Manager). 3) Define procedures for media, destruction and offline backups. 4) Review and approve the documents at least annually and after significant changes. 5) Communicate them to affected staff and keep read acknowledgements. The QSA will ask for the versioned policy, approval evidence and proof of distribution.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 215, "pagina_pdf_es": 227 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Política y procedimientos de seguridad física versionados y aprobados (generador de políticas de Kyber), matriz de responsabilidad compartida y acuses de difusión al personal.", "evidencia_en": "Versioned, approved physical security policy and procedures (Kyber policy generator), shared responsibility matrix and staff acknowledgements.", "limitaciones": "Kyber no puede confirmar que los procedimientos se apliquen en la práctica ni que el personal los conozca.", "limitaciones_en": "Kyber cannot confirm that procedures are followed in practice or that staff know them.", "responsabilidad_compartida": "compartida", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.1", "5.37", "7.1" ], "soc2_tsc": [ "CC5.3", "CC2.2" ], "cis_controls_v8": [] } }, { "id": 135, "numero_regla": "9.2.1", "requisito": "9", "seccion": "9.2", "categoria": "Requisito 9: Restringir el acceso físico a los datos de tarjetahabiente", "categoria_en": "Requirement 9: Restrict Physical Access to Cardholder Data", "seccion_titulo": "Controles de acceso físico a instalaciones y sistemas", "seccion_titulo_en": "Physical access controls manage entry into facilities and systems", "descripcion_corta": "Controles de entrada a instalaciones que restringen el acceso físico al CDE", "descripcion_larga": "Deben existir controles de entrada a las instalaciones apropiados para limitar el acceso físico a los sistemas que forman parte del entorno de datos del titular de la tarjeta (CDE). La nota de aplicabilidad aclara que no aplica a zonas de acceso público para los consumidores (titulares de tarjeta).", "remediacion": "1) Para cargas en AWS, Azure o GCP, documente que el control de acceso físico a los centros de datos lo provee el proveedor y adjunte su AOC PCI DSS vigente (AWS Artifact, Microsoft Service Trust Portal, Google Compliance Reports Manager). 2) Registre en el inventario qué componentes del CDE están en nube y cuáles en instalaciones propias. 3) Para cualquier sitio propio con componentes del CDE (oficina, rack, coubicación) implemente lectores de tarjeta, cerraduras y registro de visitantes. 4) Revise anualmente que la AOC del proveedor cubra las regiones y servicios usados. El QSA pedirá la AOC del proveedor, la matriz de responsabilidades y evidencia de controles en sitios propios.", "descripcion_corta_en": "Facility entry controls restrict physical access to CDE systems", "descripcion_larga_en": "Appropriate facility entry controls must be in place to limit physical access to systems that are part of the cardholder data environment (CDE). The applicability note states that this does not apply to areas that are publicly accessible to consumers (cardholders).", "remediacion_en": "1) For workloads in AWS, Azure or GCP, document that physical access control to data centers is provided by the provider and attach its current PCI DSS AOC (AWS Artifact, Microsoft Service Trust Portal, Google Compliance Reports Manager). 2) Record in the inventory which CDE components are in the cloud and which are on the entity's own premises. 3) For any own site hosting CDE components (office, rack, colocation) implement badge readers, locks and visitor logs. 4) Review annually that the provider AOC covers the regions and services in use. The QSA will ask for the provider AOC, the responsibility matrix and evidence of controls at own sites.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 217, "pagina_pdf_es": 229 }, "kyber_cobertura": { "tipo": "heredado_proveedor", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Reportes de cumplimiento del proveedor (AWS Artifact: AOC/ROC PCI DSS y SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager) vigentes, más la matriz de responsabilidad compartida PCI DSS del proveedor que asigne este requisito al proveedor.", "evidencia_en": "Current provider compliance reports (AWS Artifact: PCI DSS AOC/ROC and SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager), plus the provider's PCI DSS shared responsibility matrix assigning this requirement to the provider.", "limitaciones": "El escaneo no puede verificar controles físicos en centros de datos del proveedor ni en oficinas, centros de llamadas o sitios propios del cliente; para esas instalaciones el cliente debe aportar evidencia propia.", "limitaciones_en": "The scan cannot verify physical controls in provider data centers or in the customer's own offices, call centers or sites; for those facilities the customer must provide its own evidence.", "responsabilidad_compartida": "proveedor_nube", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "7.1", "7.2" ], "soc2_tsc": [ "CC6.4" ], "cis_controls_v8": [], "banxico_spei": [ "58a. II.b).3" ] } }, { "id": 136, "numero_regla": "9.2.1.1", "requisito": "9", "seccion": "9.2", "categoria": "Requisito 9: Restringir el acceso físico a los datos de tarjetahabiente", "categoria_en": "Requirement 9: Restrict Physical Access to Cardholder Data", "seccion_titulo": "Controles de acceso físico a instalaciones y sistemas", "seccion_titulo_en": "Physical access controls manage entry into facilities and systems", "descripcion_corta": "Monitoreo de acceso físico individual a áreas sensibles del CDE con cámaras o controles", "descripcion_larga": "El acceso físico individual a áreas sensibles dentro del CDE debe monitorearse mediante cámaras de video, mecanismos de control de acceso físico o ambos. Se deben vigilar los puntos de entrada y salida de dichas áreas, proteger los dispositivos de monitoreo contra manipulación o desactivación, revisar y correlacionar los datos recolectados con otros registros, y conservarlos por al menos tres meses salvo que la ley lo impida.", "remediacion": "1) En nube, este control lo cumple el proveedor en sus centros de datos; descargue su AOC/ROC y reportes SOC 2 que describan CCTV, control de acceso y retención (AWS Artifact, Service Trust Portal, Compliance Reports Manager). 2) Verifique en la matriz de responsabilidad compartida que el requisito está asignado al proveedor. 3) Si mantiene áreas sensibles propias (p. ej. cuarto de HSM o de medios), instale cámaras o lectores en entradas y salidas, protéjalos contra manipulación, correlacione sus registros con los de acceso y consérvelos 90 días o más. 4) Revise anualmente la vigencia de los reportes. El QSA pedirá los reportes del proveedor y, para sitios propios, muestras de grabaciones y registros de acceso con su retención.", "descripcion_corta_en": "Individual physical access to sensitive CDE areas monitored with cameras or access controls", "descripcion_larga_en": "Individual physical access to sensitive areas within the CDE must be monitored using video cameras, physical access control mechanisms, or both. Entry and exit points to those areas must be monitored, monitoring devices must be protected from tampering or being disabled, collected data must be reviewed and correlated with other records, and it must be kept for at least three months unless the law prevents it.", "remediacion_en": "1) In the cloud, the provider meets this control in its data centers; download its AOC/ROC and SOC 2 reports describing CCTV, access control and retention (AWS Artifact, Service Trust Portal, Compliance Reports Manager). 2) Confirm in the shared responsibility matrix that the requirement is assigned to the provider. 3) If you maintain your own sensitive areas (e.g., an HSM or media room), install cameras or badge readers at entry and exit points, protect them against tampering, correlate their records with access logs and keep them for 90 days or more. 4) Review report currency annually. The QSA will ask for provider reports and, for own sites, sample footage and access logs with their retention.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 218, "pagina_pdf_es": 230 }, "kyber_cobertura": { "tipo": "heredado_proveedor", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Reportes de cumplimiento del proveedor (AWS Artifact: AOC/ROC PCI DSS y SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager) vigentes, más la matriz de responsabilidad compartida PCI DSS del proveedor que asigne este requisito al proveedor.", "evidencia_en": "Current provider compliance reports (AWS Artifact: PCI DSS AOC/ROC and SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager), plus the provider's PCI DSS shared responsibility matrix assigning this requirement to the provider.", "limitaciones": "El escaneo no puede verificar controles físicos en centros de datos del proveedor ni en oficinas, centros de llamadas o sitios propios del cliente; para esas instalaciones el cliente debe aportar evidencia propia.", "limitaciones_en": "The scan cannot verify physical controls in provider data centers or in the customer's own offices, call centers or sites; for those facilities the customer must provide its own evidence.", "responsabilidad_compartida": "proveedor_nube", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "7.2", "7.4" ], "soc2_tsc": [ "CC6.4" ], "cis_controls_v8": [] } }, { "id": 137, "numero_regla": "9.2.2", "requisito": "9", "seccion": "9.2", "categoria": "Requisito 9: Restringir el acceso físico a los datos de tarjetahabiente", "categoria_en": "Requirement 9: Restrict Physical Access to Cardholder Data", "seccion_titulo": "Controles de acceso físico a instalaciones y sistemas", "seccion_titulo_en": "Physical access controls manage entry into facilities and systems", "descripcion_corta": "Restricción física o lógica de conectores de red accesibles al público", "descripcion_larga": "Se deben aplicar controles físicos o lógicos que restrinjan el uso de los conectores (tomas) de red ubicados en áreas accesibles al público dentro de la instalación, para evitar que una persona no autorizada conecte un dispositivo a la red interna.", "remediacion": "1) Documente que en la nube no existen conectores físicos accesibles al cliente ni al público y que la red física del centro de datos es responsabilidad del proveedor; adjunte su AOC. 2) En oficinas propias con conectividad al CDE (VPN, Direct Connect, ExpressRoute, Cloud Interconnect), desactive puertos no usados, aplique 802.1X/NAC o colóquelos en una VLAN sin ruta al CDE. 3) Revise semestralmente los puertos activos en áreas públicas. El QSA pedirá la matriz de responsabilidades y, en sitios propios, la configuración de switches o NAC.", "descripcion_corta_en": "Physical or logical restriction of publicly accessible network jacks", "descripcion_larga_en": "Physical or logical controls must restrict the use of network jacks located in publicly accessible areas of the facility, so that an unauthorized person cannot connect a device to the internal network.", "remediacion_en": "1) Document that in the cloud there are no physical jacks reachable by the customer or the public and that the data center physical network is the provider's responsibility; attach its AOC. 2) In own offices connected to the CDE (VPN, Direct Connect, ExpressRoute, Cloud Interconnect), disable unused ports, apply 802.1X/NAC or place them in a VLAN with no route to the CDE. 3) Review active ports in public areas every six months. The QSA will ask for the responsibility matrix and, at own sites, switch or NAC configuration.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 219, "pagina_pdf_es": 231 }, "kyber_cobertura": { "tipo": "heredado_proveedor", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Reportes de cumplimiento del proveedor (AWS Artifact: AOC/ROC PCI DSS y SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager) vigentes, más la matriz de responsabilidad compartida PCI DSS del proveedor que asigne este requisito al proveedor.", "evidencia_en": "Current provider compliance reports (AWS Artifact: PCI DSS AOC/ROC and SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager), plus the provider's PCI DSS shared responsibility matrix assigning this requirement to the provider.", "limitaciones": "El escaneo no puede verificar controles físicos en centros de datos del proveedor ni en oficinas, centros de llamadas o sitios propios del cliente; para esas instalaciones el cliente debe aportar evidencia propia.", "limitaciones_en": "The scan cannot verify physical controls in provider data centers or in the customer's own offices, call centers or sites; for those facilities the customer must provide its own evidence.", "responsabilidad_compartida": "proveedor_nube", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "7.12", "8.20" ], "soc2_tsc": [ "CC6.4", "CC6.6" ], "cis_controls_v8": [ "12.2" ] } }, { "id": 138, "numero_regla": "9.2.3", "requisito": "9", "seccion": "9.2", "categoria": "Requisito 9: Restringir el acceso físico a los datos de tarjetahabiente", "categoria_en": "Requirement 9: Restrict Physical Access to Cardholder Data", "seccion_titulo": "Controles de acceso físico a instalaciones y sistemas", "seccion_titulo_en": "Physical access controls manage entry into facilities and systems", "descripcion_corta": "Acceso físico restringido a puntos de acceso inalámbrico, equipo de red y líneas de telecomunicaciones", "descripcion_larga": "Debe restringirse el acceso físico a los puntos de acceso inalámbrico, puertas de enlace, hardware de redes y comunicaciones, y líneas de telecomunicaciones de la instalación, para impedir que alguien no autorizado los manipule o se conecte a ellos.", "remediacion": "1) Para la infraestructura de red de AWS, Azure y GCP, documente la herencia del control y adjunte la AOC del proveedor. 2) En sitios propios con enlaces dedicados al CDE (routers de Direct Connect, ExpressRoute o Interconnect, equipos SD-WAN, APs), ubíquelos en gabinetes o cuartos cerrados con acceso registrado. 3) Mantenga un inventario de esos equipos y revíselo al menos una vez al año. El QSA pedirá la AOC del proveedor y, en sitios propios, evidencia de cuartos/gabinetes cerrados y listas de acceso.", "descripcion_corta_en": "Physical access restricted to wireless access points, network hardware and telecom lines", "descripcion_larga_en": "Physical access to wireless access points, gateways, networking and communications hardware, and telecommunication lines within the facility must be restricted so that unauthorized people cannot tamper with or connect to them.", "remediacion_en": "1) For AWS, Azure and GCP network infrastructure, document control inheritance and attach the provider AOC. 2) At own sites with dedicated links to the CDE (Direct Connect, ExpressRoute or Interconnect routers, SD-WAN appliances, APs), place them in locked cabinets or rooms with logged access. 3) Keep an inventory of that equipment and review it at least annually. The QSA will ask for the provider AOC and, at own sites, evidence of locked rooms/cabinets and access lists.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 219, "pagina_pdf_es": 232 }, "kyber_cobertura": { "tipo": "heredado_proveedor", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Reportes de cumplimiento del proveedor (AWS Artifact: AOC/ROC PCI DSS y SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager) vigentes, más la matriz de responsabilidad compartida PCI DSS del proveedor que asigne este requisito al proveedor.", "evidencia_en": "Current provider compliance reports (AWS Artifact: PCI DSS AOC/ROC and SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager), plus the provider's PCI DSS shared responsibility matrix assigning this requirement to the provider.", "limitaciones": "El escaneo no puede verificar controles físicos en centros de datos del proveedor ni en oficinas, centros de llamadas o sitios propios del cliente; para esas instalaciones el cliente debe aportar evidencia propia.", "limitaciones_en": "The scan cannot verify physical controls in provider data centers or in the customer's own offices, call centers or sites; for those facilities the customer must provide its own evidence.", "responsabilidad_compartida": "proveedor_nube", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "7.2", "7.8", "7.12" ], "soc2_tsc": [ "CC6.4" ], "cis_controls_v8": [] } }, { "id": 139, "numero_regla": "9.3.1", "requisito": "9", "seccion": "9.3", "categoria": "Requisito 9: Restringir el acceso físico a los datos de tarjetahabiente", "categoria_en": "Requirement 9: Restrict Physical Access to Cardholder Data", "seccion_titulo": "Acceso físico de personal y visitantes autorizado y gestionado", "seccion_titulo_en": "Physical access for personnel and visitors is authorized and managed", "descripcion_corta": "Procedimientos para autorizar y gestionar el acceso físico del personal al CDE", "descripcion_larga": "Deben implementarse procedimientos para autorizar y administrar el acceso físico del personal al CDE que incluyan: identificar al personal, gestionar los cambios en sus necesidades de acceso físico, revocar o dar de baja la identificación del personal y limitar a personal autorizado el acceso al proceso o sistema de identificación.", "remediacion": "1) En nube, el personal del cliente no accede físicamente a los centros de datos; documente que el proveedor administra gafetes, altas y bajas de su personal y adjunte su AOC/SOC 2. 2) Si existen instalaciones propias del CDE, defina un flujo de alta, cambio y baja de gafetes vinculado a RR. HH., con revocación el mismo día de la salida. 3) Restrinja la administración del sistema de gafetes a personal designado y revise trimestralmente los accesos vigentes contra la plantilla. El QSA pedirá el procedimiento, muestras de altas/bajas y la lista de administradores del sistema de identificación.", "descripcion_corta_en": "Procedures to authorize and manage personnel physical access to the CDE", "descripcion_larga_en": "Procedures must be implemented to authorize and manage personnel physical access to the CDE, covering: identifying personnel, managing changes to an individual's physical access needs, revoking or terminating personnel identification, and limiting access to the identification process or system to authorized personnel.", "remediacion_en": "1) In the cloud, customer staff do not physically access data centers; document that the provider manages badges, onboarding and offboarding of its own staff and attach its AOC/SOC 2. 2) If own CDE facilities exist, define a badge onboarding, change and termination workflow tied to HR, with same-day revocation on departure. 3) Restrict administration of the badge system to designated staff and review active access against the headcount quarterly. The QSA will ask for the procedure, onboarding/termination samples and the list of identification-system administrators.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 221, "pagina_pdf_es": 233 }, "kyber_cobertura": { "tipo": "heredado_proveedor", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Reportes de cumplimiento del proveedor (AWS Artifact: AOC/ROC PCI DSS y SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager) vigentes, más la matriz de responsabilidad compartida PCI DSS del proveedor que asigne este requisito al proveedor.", "evidencia_en": "Current provider compliance reports (AWS Artifact: PCI DSS AOC/ROC and SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager), plus the provider's PCI DSS shared responsibility matrix assigning this requirement to the provider.", "limitaciones": "El escaneo no puede verificar controles físicos en centros de datos del proveedor ni en oficinas, centros de llamadas o sitios propios del cliente; para esas instalaciones el cliente debe aportar evidencia propia.", "limitaciones_en": "The scan cannot verify physical controls in provider data centers or in the customer's own offices, call centers or sites; for those facilities the customer must provide its own evidence.", "responsabilidad_compartida": "proveedor_nube", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "7.2", "5.18" ], "soc2_tsc": [ "CC6.4" ], "cis_controls_v8": [], "banxico_spei": [ "58a. II.b).3" ] } }, { "id": 140, "numero_regla": "9.4.1", "requisito": "9", "seccion": "9.4", "categoria": "Requisito 9: Restringir el acceso físico a los datos de tarjetahabiente", "categoria_en": "Requirement 9: Restrict Physical Access to Cardholder Data", "seccion_titulo": "Medios con datos de tarjetahabiente almacenados, distribuidos y destruidos de forma segura", "seccion_titulo_en": "Media with cardholder data is securely stored, distributed, and destroyed", "descripcion_corta": "Protección física de todos los medios con datos del titular de la tarjeta", "descripcion_larga": "Todos los medios que contengan datos del titular de la tarjeta, sean electrónicos o en papel, deben estar físicamente protegidos para evitar su acceso, copia o sustracción no autorizados.", "remediacion": "1) Documente que los discos, cintas y demás medios físicos que respaldan EBS/S3, Azure Disks/Storage y Persistent Disk/Cloud Storage están bajo custodia física del proveedor y adjunte su AOC. 2) Prohíba copiar datos del titular de la tarjeta a medios removibles o equipos locales; si es inevitable, guárdelos cifrados en caja fuerte o gabinete con llave y bitácora. 3) Mantenga cifrado en reposo con KMS/Key Vault/Cloud KMS en todos los almacenes del CDE como control compensatorio frente a pérdida física. El QSA pedirá la AOC del proveedor y la política de manejo de medios del cliente.", "descripcion_corta_en": "Physical protection of all media containing cardholder data", "descripcion_larga_en": "All media containing cardholder data, whether electronic or paper, must be physically secured to prevent unauthorized access, copying or removal.", "remediacion_en": "1) Document that the disks, tapes and other physical media backing EBS/S3, Azure Disks/Storage and Persistent Disk/Cloud Storage are in the provider's physical custody and attach its AOC. 2) Prohibit copying cardholder data to removable media or local devices; if unavoidable, store it encrypted in a safe or locked cabinet with a log. 3) Keep encryption at rest with KMS/Key Vault/Cloud KMS on all CDE stores as a safeguard against physical loss. The QSA will ask for the provider AOC and the customer's media handling policy.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 225, "pagina_pdf_es": 237 }, "kyber_cobertura": { "tipo": "heredado_proveedor", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Reportes de cumplimiento del proveedor (AWS Artifact: AOC/ROC PCI DSS y SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager) vigentes, más la matriz de responsabilidad compartida PCI DSS del proveedor que asigne este requisito al proveedor. Además, política de manejo de medios del cliente.", "evidencia_en": "Current provider compliance reports (AWS Artifact: PCI DSS AOC/ROC and SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager), plus the provider's PCI DSS shared responsibility matrix assigning this requirement to the provider. Also the customer's media handling policy.", "limitaciones": "El escaneo no puede verificar controles físicos en centros de datos del proveedor ni en oficinas, centros de llamadas o sitios propios del cliente; para esas instalaciones el cliente debe aportar evidencia propia.", "limitaciones_en": "The scan cannot verify physical controls in provider data centers or in the customer's own offices, call centers or sites; for those facilities the customer must provide its own evidence.", "responsabilidad_compartida": "compartida", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "7.10" ], "soc2_tsc": [ "CC6.4", "CC6.7" ], "cis_controls_v8": [ "3.9" ], "banxico_spei": [ "58a. I.A.d).2", "58a. I.A.g).5" ] } }, { "id": 141, "numero_regla": "9.4.1.1", "requisito": "9", "seccion": "9.4", "categoria": "Requisito 9: Restringir el acceso físico a los datos de tarjetahabiente", "categoria_en": "Requirement 9: Restrict Physical Access to Cardholder Data", "seccion_titulo": "Medios con datos de tarjetahabiente almacenados, distribuidos y destruidos de forma segura", "seccion_titulo_en": "Media with cardholder data is securely stored, distributed, and destroyed", "descripcion_corta": "Respaldos fuera de línea con datos de tarjeta resguardados en ubicación segura", "descripcion_larga": "Los respaldos en medios fuera de línea que contengan datos del titular de la tarjeta deben almacenarse en una ubicación segura, de forma que personal no autorizado no pueda acceder a ellos.", "remediacion": "1) Documente que el almacenamiento físico de respaldos en nube (AWS Backup, Azure Backup, GCP Backup and DR) es responsabilidad del proveedor y adjunte su AOC. 2) Complemente con controles lógicos del cliente: AWS Backup Vault Lock en modo compliance con copia cruzada a otra región/cuenta, Azure Backup con bóveda inmutable (immutability bloqueada) y soft delete, y GCP backup vault con período de retención forzado. 3) Cifre los respaldos con llaves administradas por el cliente y limite con IAM quién puede restaurar o borrar. 4) Si hay cintas o discos físicos propios, guárdelos en una bóveda o con un custodio externo certificado. El QSA pedirá la AOC del proveedor y la configuración de bóvedas, cifrado y permisos.", "descripcion_corta_en": "Offline media backups with cardholder data stored in a secure location", "descripcion_larga_en": "Offline media backups containing cardholder data must be stored in a secure location so that unauthorized personnel cannot access them.", "remediacion_en": "1) Document that physical storage of cloud backups (AWS Backup, Azure Backup, GCP Backup and DR) is the provider's responsibility and attach its AOC. 2) Complement with customer logical controls: AWS Backup Vault Lock in compliance mode with cross-region/cross-account copy, Azure Backup immutable vault (locked immutability) with soft delete, and GCP backup vault with an enforced retention period. 3) Encrypt backups with customer-managed keys and restrict through IAM who can restore or delete. 4) If own tapes or physical disks exist, keep them in a vault or with a certified off-site custodian. The QSA will ask for the provider AOC and the vault, encryption and permission configuration.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 225, "pagina_pdf_es": 237 }, "kyber_cobertura": { "tipo": "heredado_proveedor", "automatizacion": "media", "checks_aws": [ "AWS Backup: bóvedas del CDE con Vault Lock (modo compliance) configurado (falla si no existe)", "AWS Backup: plan con copia cross-region o cross-account para recursos del CDE", "AWS Backup: recovery points cifrados [Backup.1]", "Políticas de acceso de la bóveda que niegan DeleteRecoveryPoint a principales no autorizados" ], "checks_azure": [ "Azure Recovery Services/Backup vault: immutabilitySettings.state = Locked (falla si Disabled)", "Azure Backup vault: softDeleteSettings habilitado", "Azure Backup vault: cifrado con llave administrada por el cliente (CMK) para el CDE" ], "checks_gcp": [ "GCP Backup and DR: backup vault con enforced minimum retention configurado", "GCP: respaldos/snapshots del CDE cifrados con CMEK de Cloud KMS", "GCP IAM: roles de borrado de respaldos limitados a cuentas de administración designadas" ], "evidencia": "Reportes de cumplimiento del proveedor (AWS Artifact: AOC/ROC PCI DSS y SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager) vigentes, más la matriz de responsabilidad compartida PCI DSS del proveedor que asigne este requisito al proveedor. Además, Kyber reporta la configuración de inmutabilidad, cifrado y copia cruzada de las bóvedas de respaldo.", "evidencia_en": "Current provider compliance reports (AWS Artifact: PCI DSS AOC/ROC and SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager), plus the provider's PCI DSS shared responsibility matrix assigning this requirement to the provider. Kyber also reports immutability, encryption and cross-copy configuration of backup vaults.", "limitaciones": "El escaneo verifica controles lógicos de las bóvedas en nube, no la custodia física de medios ni respaldos fuera de la nube.", "limitaciones_en": "The scan verifies logical controls on cloud vaults, not physical media custody or backups outside the cloud.", "responsabilidad_compartida": "compartida", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "7.10", "8.13" ], "soc2_tsc": [ "CC6.4", "A1.2" ], "cis_controls_v8": [ "11.3", "11.4" ] } }, { "id": 142, "numero_regla": "9.4.1.2", "requisito": "9", "seccion": "9.4", "categoria": "Requisito 9: Restringir el acceso físico a los datos de tarjetahabiente", "categoria_en": "Requirement 9: Restrict Physical Access to Cardholder Data", "seccion_titulo": "Medios con datos de tarjetahabiente almacenados, distribuidos y destruidos de forma segura", "seccion_titulo_en": "Media with cardholder data is securely stored, distributed, and destroyed", "descripcion_corta": "Revisión anual de la seguridad de la ubicación de respaldos fuera de línea", "descripcion_larga": "La seguridad de la ubicación donde se almacenan los respaldos fuera de línea con datos del titular de la tarjeta debe revisarse al menos una vez cada 12 meses.", "remediacion": "1) Para respaldos en nube, conserve cada año la AOC/SOC 2 vigente del proveedor como evidencia de la revisión de la seguridad física. 2) Como complemento, revise anualmente la configuración lógica de las bóvedas (Vault Lock, inmutabilidad, permisos, cifrado) y documente el resultado. 3) Si usa un custodio externo de medios, obtenga su certificación o realice una visita anual con checklist. 4) Registre fecha, responsable y hallazgos de la revisión. El QSA pedirá el registro de la revisión de los últimos 12 meses.", "descripcion_corta_en": "Annual review of offline backup location security", "descripcion_larga_en": "The security of the location where offline backups containing cardholder data are stored must be reviewed at least once every 12 months.", "remediacion_en": "1) For cloud backups, keep the provider's current AOC/SOC 2 each year as evidence of the physical security review. 2) In addition, review annually the logical configuration of vaults (Vault Lock, immutability, permissions, encryption) and document the outcome. 3) If an off-site media custodian is used, obtain its certification or perform an annual site visit with a checklist. 4) Record date, owner and findings of the review. The QSA will ask for the review record from the last 12 months.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 226, "pagina_pdf_es": 238 }, "kyber_cobertura": { "tipo": "heredado_proveedor", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Reportes de cumplimiento del proveedor (AWS Artifact: AOC/ROC PCI DSS y SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager) vigentes, más la matriz de responsabilidad compartida PCI DSS del proveedor que asigne este requisito al proveedor. Además, registro anual de la revisión del cliente.", "evidencia_en": "Current provider compliance reports (AWS Artifact: PCI DSS AOC/ROC and SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager), plus the provider's PCI DSS shared responsibility matrix assigning this requirement to the provider. Also the customer's annual review record.", "limitaciones": "El escaneo no puede verificar controles físicos en centros de datos del proveedor ni en oficinas, centros de llamadas o sitios propios del cliente; para esas instalaciones el cliente debe aportar evidencia propia.", "limitaciones_en": "The scan cannot verify physical controls in provider data centers or in the customer's own offices, call centers or sites; for those facilities the customer must provide its own evidence.", "responsabilidad_compartida": "compartida", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "7.10", "8.13" ], "soc2_tsc": [ "CC6.4", "A1.2" ], "cis_controls_v8": [ "11.3" ] } }, { "id": 143, "numero_regla": "9.4.6", "requisito": "9", "seccion": "9.4", "categoria": "Requisito 9: Restringir el acceso físico a los datos de tarjetahabiente", "categoria_en": "Requirement 9: Restrict Physical Access to Cardholder Data", "seccion_titulo": "Medios con datos de tarjetahabiente almacenados, distribuidos y destruidos de forma segura", "seccion_titulo_en": "Media with cardholder data is securely stored, distributed, and destroyed", "descripcion_corta": "Destrucción segura de material impreso con datos de tarjeta cuando ya no se requiere", "descripcion_larga": "Los materiales impresos con datos del titular de la tarjeta deben destruirse cuando dejan de ser necesarios por motivos de negocio o legales, mediante trituración de corte cruzado, incineración o reducción a pulpa, de modo que no puedan reconstruirse; mientras esperan su destrucción deben guardarse en contenedores seguros. Esta destrucción de medios es distinta del borrado seguro de datos por política de retención del Requisito 3.2.1.", "remediacion": "1) Inventaríe los procesos que imprimen datos del titular de la tarjeta (contracargos, conciliaciones, formularios) y elimínelos cuando sea posible. 2) Coloque contenedores cerrados con llave para material pendiente de destrucción. 3) Use trituradoras de corte cruzado o un proveedor de destrucción certificado que entregue certificados de destrucción. 4) Defina la frecuencia de recolección y conserve los certificados. Este control es del cliente: el proveedor de nube no maneja papel. El QSA pedirá la política, la ubicación de contenedores y certificados de destrucción recientes.", "descripcion_corta_en": "Secure destruction of hard-copy materials with cardholder data when no longer needed", "descripcion_larga_en": "Hard-copy materials containing cardholder data must be destroyed when no longer needed for business or legal reasons, by cross-cut shredding, incineration or pulping so they cannot be reconstructed; while awaiting destruction they must be kept in secure containers. This media destruction is distinct from the retention-driven secure deletion of data in Requirement 3.2.1.", "remediacion_en": "1) Inventory processes that print cardholder data (chargebacks, reconciliations, forms) and eliminate them where possible. 2) Place locked containers for material awaiting destruction. 3) Use cross-cut shredders or a certified destruction vendor that issues certificates of destruction. 4) Define the collection frequency and keep the certificates. This control belongs to the customer: the cloud provider does not handle paper. The QSA will ask for the policy, container locations and recent destruction certificates.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 230, "pagina_pdf_es": 242 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Política de destrucción de papel, fotografías de contenedores seguros y certificados de destrucción del proveedor de trituración.", "evidencia_en": "Paper destruction policy, photos of secure containers and certificates of destruction from the shredding vendor.", "limitaciones": "Kyber no tiene visibilidad sobre material impreso; depende totalmente de evidencia cargada por el cliente.", "limitaciones_en": "Kyber has no visibility into printed material; it relies entirely on customer-uploaded evidence.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "7.10", "7.14" ], "soc2_tsc": [ "CC6.5" ], "cis_controls_v8": [ "3.5" ] } }, { "id": 144, "numero_regla": "9.4.7", "requisito": "9", "seccion": "9.4", "categoria": "Requisito 9: Restringir el acceso físico a los datos de tarjetahabiente", "categoria_en": "Requirement 9: Restrict Physical Access to Cardholder Data", "seccion_titulo": "Medios con datos de tarjetahabiente almacenados, distribuidos y destruidos de forma segura", "seccion_titulo_en": "Media with cardholder data is securely stored, distributed, and destroyed", "descripcion_corta": "Destrucción de medios electrónicos o datos irrecuperables cuando ya no se requieren", "descripcion_larga": "Los medios electrónicos con datos del titular de la tarjeta deben destruirse cuando ya no se necesitan por razones de negocio o legales, ya sea destruyendo físicamente el medio o haciendo que los datos sean irrecuperables de forma que no puedan reconstruirse. Esta destrucción es distinta del borrado seguro por política de retención del Requisito 3.2.1.", "remediacion": "1) Documente que la sanitización y destrucción de discos físicos al final de su vida útil la realiza el proveedor (NIST 800-88) y adjunte su AOC. 2) Como complemento, aplique borrado criptográfico: cifre volúmenes, buckets, bases de datos y respaldos del CDE con llaves de KMS/Key Vault/Cloud KMS y, al retirar el dato, programe la eliminación de la llave (ScheduleKeyDeletion, purge en Key Vault, destroy de versiones en Cloud KMS). 3) Elimine volúmenes no adjuntos, snapshots e imágenes huérfanas que contengan datos del CDE. 4) Prohíba medios removibles o, si existen, use borrado certificado o destrucción física con certificado. El QSA pedirá la AOC del proveedor, el procedimiento de retiro de datos y evidencia de llaves eliminadas o recursos borrados.", "descripcion_corta_en": "Electronic media destroyed or data rendered unrecoverable when no longer needed", "descripcion_larga_en": "Electronic media containing cardholder data must be destroyed when no longer needed for business or legal reasons, either by physically destroying the media or by rendering the data unrecoverable so it cannot be reconstructed. This destruction is distinct from the retention-driven secure deletion in Requirement 3.2.1.", "remediacion_en": "1) Document that sanitization and destruction of physical disks at end of life is performed by the provider (NIST 800-88) and attach its AOC. 2) As a complement, apply cryptographic erasure: encrypt CDE volumes, buckets, databases and backups with KMS/Key Vault/Cloud KMS keys and, when data is retired, schedule key deletion (ScheduleKeyDeletion, Key Vault purge, Cloud KMS version destroy). 3) Delete unattached volumes, orphaned snapshots and images containing CDE data. 4) Prohibit removable media or, where used, apply certified wiping or physical destruction with a certificate. The QSA will ask for the provider AOC, the data retirement procedure and evidence of deleted keys or resources.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 231, "pagina_pdf_es": 243 }, "kyber_cobertura": { "tipo": "heredado_proveedor", "automatizacion": "media", "checks_aws": [ "EBS: volúmenes adjuntos cifrados [EC2.3] y cifrado por defecto habilitado en la región [EC2.7]", "EBS: volúmenes en estado available (no adjuntos) por más de N días (falla si existen)", "Snapshots EBS/RDS e AMIs huérfanos de recursos del CDE eliminados", "KMS: llaves en estado PendingDeletion registradas y alineadas con retiro de datos documentado" ], "checks_azure": [ "Managed Disks: discos con diskState = Unattached en el CDE (falla si existen)", "Discos, Storage y SQL del CDE cifrados con CMK de Key Vault", "Key Vault: soft delete y purge protection configurados según el procedimiento de borrado criptográfico" ], "checks_gcp": [ "Persistent Disk: discos sin users[] (no adjuntos) en proyectos del CDE (falla si existen)", "Discos, buckets y Cloud SQL del CDE cifrados con CMEK de Cloud KMS", "Cloud KMS: versiones de llave en DESTROY_SCHEDULED/DESTROYED documentadas en el retiro de datos" ], "evidencia": "Reportes de cumplimiento del proveedor (AWS Artifact: AOC/ROC PCI DSS y SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager) vigentes, más la matriz de responsabilidad compartida PCI DSS del proveedor que asigne este requisito al proveedor. Además, Kyber lista volúmenes no adjuntos, snapshots huérfanos y el estado de cifrado y de llaves KMS.", "evidencia_en": "Current provider compliance reports (AWS Artifact: PCI DSS AOC/ROC and SOC 2; Microsoft Service Trust Portal; Google Compliance Reports Manager), plus the provider's PCI DSS shared responsibility matrix assigning this requirement to the provider. Kyber also lists unattached volumes, orphaned snapshots and encryption and KMS key status.", "limitaciones": "El escaneo no puede verificar la destrucción física de discos del proveedor ni de medios removibles del cliente, ni confirmar que no existan copias fuera de la nube.", "limitaciones_en": "The scan cannot verify physical destruction of provider disks or customer removable media, nor confirm that no copies exist outside the cloud.", "responsabilidad_compartida": "compartida", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "7.14", "8.10" ], "soc2_tsc": [ "CC6.5" ], "cis_controls_v8": [ "3.5" ], "banxico_spei": [ "58a. I.A.d).1" ] } }, { "id": 145, "numero_regla": "10.1.1", "requisito": "10", "seccion": "10.1", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Procesos y mecanismos de registro y monitoreo definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for logging and monitoring are defined and understood", "descripcion_corta": "Políticas y procedimientos operativos de registro y monitoreo (Requisito 10) gestionados", "descripcion_larga": "Las políticas de seguridad y procedimientos operativos definidos para el Requisito 10 (registro y monitoreo de todo acceso a los componentes del sistema y a los datos del titular de la tarjeta) deben estar documentados, actualizados, en uso y ser conocidos por todas las partes afectadas.", "remediacion": "1) Elabore una política de registro y monitoreo que cubra fuentes de bitácoras en nube (CloudTrail, Azure Activity Log, Cloud Audit Logs, flow logs, logs de SO y aplicación), protección, revisión diaria, retención de 12 meses, sincronización de tiempo y respuesta a fallas de controles. 2) Documente procedimientos operativos (runbooks) para la revisión de alertas en GuardDuty/Security Hub, Sentinel o Security Command Center. 3) Revise y apruebe los documentos al menos anualmente y tras cambios. 4) Difúndalos al personal de operaciones y seguridad con acuses. El QSA pedirá la política versionada, aprobación y evidencia de difusión.", "descripcion_corta_en": "Logging and monitoring policies and operational procedures (Requirement 10) are managed", "descripcion_larga_en": "Security policies and operational procedures defined for Requirement 10 (logging and monitoring all access to system components and cardholder data) must be documented, kept current, in use and known to all affected parties.", "remediacion_en": "1) Write a logging and monitoring policy covering cloud log sources (CloudTrail, Azure Activity Log, Cloud Audit Logs, flow logs, OS and application logs), protection, daily review, 12-month retention, time synchronization and response to control failures. 2) Document operational procedures (runbooks) for reviewing alerts in GuardDuty/Security Hub, Sentinel or Security Command Center. 3) Review and approve documents at least annually and after changes. 4) Distribute them to operations and security staff with acknowledgements. The QSA will ask for the versioned policy, approval and proof of distribution.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 241, "pagina_pdf_es": 251 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Política y procedimientos de registro y monitoreo versionados y aprobados (generador de políticas de Kyber) y acuses de difusión.", "evidencia_en": "Versioned, approved logging and monitoring policy and procedures (Kyber policy generator) and distribution acknowledgements.", "limitaciones": "Kyber no puede confirmar que los procedimientos se apliquen ni que el personal los conozca.", "limitaciones_en": "Kyber cannot confirm that procedures are applied or known by staff.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.1", "5.37", "8.15" ], "soc2_tsc": [ "CC5.3", "CC2.2" ], "cis_controls_v8": [ "8.1" ] } }, { "id": 146, "numero_regla": "10.1.2", "requisito": "10", "seccion": "10.1", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Procesos y mecanismos de registro y monitoreo definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for logging and monitoring are defined and understood", "descripcion_corta": "Roles y responsabilidades del Requisito 10 documentados, asignados y comprendidos", "descripcion_larga": "Los roles y responsabilidades para ejecutar las actividades del Requisito 10 deben estar documentados, asignados y ser comprendidos por el personal responsable, de modo que la rendición de cuentas sobre el registro y monitoreo sea clara.", "remediacion": "1) Elabore una matriz RACI para configuración de bitácoras en cada nube, revisión diaria de eventos, gestión de retención, sincronización de tiempo y respuesta a fallas de controles. 2) Asigne nombres concretos (no solo áreas) y suplentes. 3) Incluya las responsabilidades en descripciones de puesto o en la herramienta de gestión de turnos/guardias. 4) Obtenga confirmación del personal asignado y revise la matriz anualmente. El QSA pedirá la matriz, evidencia de asignación y entrevistará al personal.", "descripcion_corta_en": "Requirement 10 roles and responsibilities documented, assigned and understood", "descripcion_larga_en": "Roles and responsibilities for performing Requirement 10 activities must be documented, assigned and understood by the responsible personnel, so that accountability for logging and monitoring is clear.", "remediacion_en": "1) Build a RACI matrix for log configuration in each cloud, daily event review, retention management, time synchronization and response to control failures. 2) Assign named individuals (not just teams) and backups. 3) Include the responsibilities in job descriptions or the on-call tooling. 4) Obtain confirmation from assigned staff and review the matrix annually. The QSA will ask for the matrix and assignment evidence and will interview staff.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 242, "pagina_pdf_es": 252 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Matriz RACI del Requisito 10 con responsables nominales y acuses de aceptación.", "evidencia_en": "Requirement 10 RACI matrix with named owners and acceptance acknowledgements.", "limitaciones": "Kyber no puede verificar que el personal comprenda sus responsabilidades.", "limitaciones_en": "Kyber cannot verify that staff understand their responsibilities.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.2", "5.3" ], "soc2_tsc": [ "CC1.3", "CC1.4" ], "cis_controls_v8": [] } }, { "id": 147, "numero_regla": "10.2.1", "requisito": "10", "seccion": "10.2", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría implementados para detección y análisis forense", "seccion_titulo_en": "Audit logs support detection of anomalies and forensic analysis", "descripcion_corta": "Registros de auditoría habilitados y activos en todos los componentes y datos de tarjeta", "descripcion_larga": "Los registros de auditoría deben estar habilitados y activos para todos los componentes del sistema y para los datos del titular de la tarjeta, de manera que se puedan reconstruir y detectar actividades sospechosas.", "remediacion": "1) AWS: cree un trail de CloudTrail multi-región (idealmente de organización) con eventos de administración de lectura y escritura, habilite data events en los buckets S3 y tablas del CDE, VPC Flow Logs en todas las VPC, y logs de ELB, CloudFront, WAF y RDS hacia CloudWatch Logs o S3. 2) Azure: configure Diagnostic settings de la suscripción (Activity Log) y de cada recurso del CDE, NSG/VNet flow logs y registros de Entra ID hacia un espacio de Log Analytics. 3) GCP: habilite Cloud Audit Logs Admin Activity y Data Access (DATA_READ/DATA_WRITE) para servicios del CDE, VPC flow logs y un sink agregado de organización. 4) En VMs, despliegue auditd/journald o el agente de Windows y envíe a la plataforma central. El QSA pedirá configuraciones de cada fuente y muestras de eventos.", "descripcion_corta_en": "Audit logs enabled and active for all system components and cardholder data", "descripcion_larga_en": "Audit logs must be enabled and active for all system components and for cardholder data so that activity can be reconstructed and suspicious behavior detected.", "remediacion_en": "1) AWS: create a multi-region CloudTrail trail (preferably organization-wide) with read and write management events, enable data events on CDE S3 buckets and tables, VPC Flow Logs on all VPCs, and ELB, CloudFront, WAF and RDS logs to CloudWatch Logs or S3. 2) Azure: configure subscription Diagnostic settings (Activity Log) and per-resource diagnostics for the CDE, NSG/VNet flow logs and Entra ID logs to a Log Analytics workspace. 3) GCP: enable Cloud Audit Logs Admin Activity and Data Access (DATA_READ/DATA_WRITE) for CDE services, VPC flow logs and an organization aggregated sink. 4) On VMs, deploy auditd/journald or the Windows agent and ship to the central platform. The QSA will ask for configuration of each source and sample events.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 243, "pagina_pdf_es": 253 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "CloudTrail multi-región habilitado con eventos de administración de lectura y escritura [CloudTrail.1]", "CloudTrail con data events de S3 para lectura y escritura [S3.22] [S3.23]", "VPC Flow Logs habilitados en todas las VPC [EC2.6]", "Logging habilitado en ALB/CLB [ELB.5], distribuciones CloudFront [CloudFront.5] y web ACLs de WAF [WAF.11]", "RDS con exportación de logs a CloudWatch Logs [RDS.9]", "AWS Config habilitado en todas las regiones [Config.1]" ], "checks_azure": [ "Diagnostic setting de Activity Log de la suscripción enviando a Log Analytics (falla si no existe)", "Diagnostic settings habilitados en Key Vault, SQL, Storage, App Service y Application Gateway del CDE", "NSG/VNet flow logs habilitados con Traffic Analytics", "Entra ID: SignInLogs y AuditLogs exportados a Log Analytics" ], "checks_gcp": [ "Cloud Audit Logs: auditConfigs con DATA_READ y DATA_WRITE para allServices en proyectos del CDE", "Sink agregado de organización exportando todos los logs a un destino central", "VPC flow logs habilitados en todas las subredes del CDE", "Cloud SQL con flags de auditoría (cloudsql.enable_pgaudit / log_connections) habilitados" ], "evidencia": "Reporte de Kyber con el estado de cada fuente de bitácoras por cuenta, suscripción y proyecto, más muestras de eventos.", "evidencia_en": "Kyber report of each log source status per account, subscription and project, plus sample events.", "limitaciones": "Kyber no puede confirmar el registro a nivel de aplicación ni de bases de datos autogestionadas si no se expone en configuración o snapshots.", "limitaciones_en": "Kyber cannot confirm application-level logging or self-managed database logging unless exposed in configuration or snapshots.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.15" ], "soc2_tsc": [ "CC7.2" ], "cis_controls_v8": [ "8.2", "8.5", "13.6" ], "banxico_spei": [ "58a. I.A.b).5 bis", "58a. I.A.c).5", "58a. I.A.c).6", "58a. I.A.d).3", "58a. I.A.e).5", "58a. I.A.f).5" ] }, "mapeo_ucf": [ { "clave": "UCF-LOG-001", "relacion": "equivalent", "cobertura_pct": 90 } ] }, { "id": 148, "numero_regla": "10.2.1.1", "requisito": "10", "seccion": "10.2", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría implementados para detección y análisis forense", "seccion_titulo_en": "Audit logs support detection of anomalies and forensic analysis", "descripcion_corta": "Registro de todo acceso individual de usuarios a los datos del titular de la tarjeta", "descripcion_larga": "Los registros de auditoría deben capturar cada acceso individual de usuarios a los datos del titular de la tarjeta, para identificar quién accedió o pudo haber robado datos.", "remediacion": "1) AWS: habilite data events de CloudTrail (GetObject/PutObject) en buckets S3 con datos de tarjeta, data events de DynamoDB si aplica, y auditoría de base de datos (pgaudit en RDS PostgreSQL, audit plugin en MySQL/MariaDB) exportada a CloudWatch Logs. 2) Azure: habilite auditoría de Azure SQL y diagnostic logs StorageRead de los Storage Accounts del CDE hacia Log Analytics. 3) GCP: habilite Data Access logs (DATA_READ) para Cloud Storage, Cloud SQL y BigQuery del CDE. 4) Asegure que la aplicación registre consultas de PAN con el usuario final, no solo la cuenta de servicio. El QSA pedirá muestras de eventos de acceso a datos de tarjeta atribuibles a un individuo.", "descripcion_corta_en": "Logging of all individual user access to cardholder data", "descripcion_larga_en": "Audit logs must capture every individual user access to cardholder data, so it is possible to identify who accessed or may have stolen data.", "remediacion_en": "1) AWS: enable CloudTrail data events (GetObject/PutObject) on S3 buckets holding card data, DynamoDB data events where applicable, and database auditing (pgaudit on RDS PostgreSQL, audit plugin on MySQL/MariaDB) exported to CloudWatch Logs. 2) Azure: enable Azure SQL auditing and StorageRead diagnostic logs on CDE Storage Accounts to Log Analytics. 3) GCP: enable Data Access logs (DATA_READ) for CDE Cloud Storage, Cloud SQL and BigQuery. 4) Ensure the application logs PAN lookups with the end user, not just the service account. The QSA will ask for sample card-data access events attributable to an individual.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 243, "pagina_pdf_es": 253 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "CloudTrail data events de lectura en buckets S3 del CDE [S3.23]", "RDS del CDE con audit logging (pgaudit / MARIADB_AUDIT_PLUGIN) exportado a CloudWatch Logs", "DynamoDB del CDE con data events en CloudTrail (falla si no hay selector)" ], "checks_azure": [ "Azure SQL: auditingSettings.state = Enabled en servidores del CDE", "Storage Accounts del CDE con diagnostic logs StorageRead habilitados" ], "checks_gcp": [ "Data Access logs DATA_READ habilitados para storage.googleapis.com, cloudsql y bigquery en proyectos del CDE", "Cloud SQL PostgreSQL con cloudsql.enable_pgaudit = on" ], "evidencia": "Configuración de data events y auditoría de bases de datos por recurso del CDE, más muestras de eventos.", "evidencia_en": "Data event and database audit configuration per CDE resource, plus sample events.", "limitaciones": "El acceso a PAN a través de la aplicación con cuentas de servicio compartidas no se puede atribuir a un individuo solo con logs de nube; requiere registro de aplicación.", "limitaciones_en": "PAN access through the application using shared service accounts cannot be attributed to an individual from cloud logs alone; it requires application logging.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.15" ], "soc2_tsc": [ "CC7.2" ], "cis_controls_v8": [ "8.2", "8.5", "3.14" ] } }, { "id": 149, "numero_regla": "10.2.1.2", "requisito": "10", "seccion": "10.2", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría implementados para detección y análisis forense", "seccion_titulo_en": "Audit logs support detection of anomalies and forensic analysis", "descripcion_corta": "Registro de todas las acciones de individuos con acceso administrativo", "descripcion_larga": "Los registros de auditoría deben capturar todas las acciones realizadas por cualquier persona con acceso administrativo, incluido el uso interactivo de cuentas de aplicación o de sistema.", "remediacion": "1) AWS: CloudTrail multi-región con eventos de administración de lectura y escritura; use IAM Identity Center para que cada acción se atribuya a una persona y alerte sobre uso de root. 2) Habilite registro de sesiones de SSM Session Manager (S3/CloudWatch) en lugar de SSH directo. 3) Azure: Activity Log y AuditLogs de Entra ID a Log Analytics; use PIM y Azure Bastion con registro. 4) GCP: Admin Activity logs (siempre activos) y Data Access para servicios de administración; registre sesiones de OS Login/IAP. 5) En SO, configure auditd/sudo logging para capturar comandos privilegiados. El QSA pedirá muestras de acciones administrativas atribuibles a individuos.", "descripcion_corta_en": "Logging of all actions by individuals with administrative access", "descripcion_larga_en": "Audit logs must capture all actions performed by anyone with administrative access, including interactive use of application or system accounts.", "remediacion_en": "1) AWS: multi-region CloudTrail with read and write management events; use IAM Identity Center so each action is attributable to a person and alert on root usage. 2) Enable SSM Session Manager session logging (S3/CloudWatch) instead of direct SSH. 3) Azure: Activity Log and Entra ID AuditLogs to Log Analytics; use PIM and Azure Bastion with logging. 4) GCP: Admin Activity logs (always on) plus Data Access for admin services; log OS Login/IAP sessions. 5) At OS level, configure auditd/sudo logging to capture privileged commands. The QSA will ask for sample administrative actions attributable to individuals.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 244, "pagina_pdf_es": 254 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "CloudTrail multi-región con ReadWriteType = All [CloudTrail.1]", "Alarma de CloudWatch para uso de la cuenta root [CloudWatch.1]", "SSM Session Manager con registro de sesiones en S3 o CloudWatch Logs habilitado", "Snapshots de EC2: reglas auditd para execve con euid=0 y registro de sudo presentes" ], "checks_azure": [ "Activity Log exportado a Log Analytics vía Diagnostic setting", "Entra ID AuditLogs exportados a Log Analytics", "Azure Bastion con diagnostic logs (BastionAuditLogs) habilitados" ], "checks_gcp": [ "Admin Activity audit logs enrutados a sink central (no excluidos)", "Data Access logs habilitados para IAM y Compute en proyectos del CDE", "Snapshots de VMs: auditd configurado para comandos privilegiados" ], "evidencia": "Configuración de CloudTrail/Activity Log/Audit Logs y del registro de sesiones administrativas, con muestras.", "evidencia_en": "CloudTrail/Activity Log/Audit Logs and administrative session logging configuration, with samples.", "limitaciones": "Acciones dentro de aplicaciones o consolas de bases de datos no se observan si la aplicación no las registra.", "limitaciones_en": "Actions inside applications or database consoles are not observed unless the application logs them.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.15", "8.2" ], "soc2_tsc": [ "CC7.2", "CC6.1" ], "cis_controls_v8": [ "8.2", "8.5", "5.4" ], "banxico_spei": [ "58a. I.A.f).8" ] } }, { "id": 150, "numero_regla": "10.2.1.3", "requisito": "10", "seccion": "10.2", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría implementados para detección y análisis forense", "seccion_titulo_en": "Audit logs support detection of anomalies and forensic analysis", "descripcion_corta": "Registro de todo acceso a los registros de auditoría", "descripcion_larga": "Los registros de auditoría deben capturar todos los accesos a las propias bitácoras de auditoría, para detectar intentos de ocultar actividad maliciosa.", "remediacion": "1) AWS: habilite data events de CloudTrail y S3 server access logging en el bucket de bitácoras de CloudTrail; los accesos a CloudWatch Logs (GetLogEvents, FilterLogEvents) quedan como eventos de administración. 2) Azure: habilite diagnostic settings del espacio de Log Analytics (LAQueryLogs) y StorageRead en la cuenta de almacenamiento de archivado. 3) GCP: habilite Data Access logs para logging.googleapis.com y storage.googleapis.com en el proyecto de bitácoras. 4) Alerte ante accesos de identidades no autorizadas. El QSA pedirá muestras de eventos de lectura de bitácoras.", "descripcion_corta_en": "Logging of all access to audit logs", "descripcion_larga_en": "Audit logs must capture all access to the audit logs themselves, to detect attempts to hide malicious activity.", "remediacion_en": "1) AWS: enable CloudTrail data events and S3 server access logging on the CloudTrail log bucket; access to CloudWatch Logs (GetLogEvents, FilterLogEvents) is captured as management events. 2) Azure: enable Log Analytics workspace diagnostic settings (LAQueryLogs) and StorageRead on the archive storage account. 3) GCP: enable Data Access logs for logging.googleapis.com and storage.googleapis.com in the logging project. 4) Alert on access by unauthorized identities. The QSA will ask for sample log-read events.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 244, "pagina_pdf_es": 254 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Bucket S3 de CloudTrail con server access logging habilitado [CloudTrail.7]", "CloudTrail con data events de lectura sobre el bucket de bitácoras", "CloudTrail registra eventos de administración de lectura (captura GetLogEvents/FilterLogEvents)" ], "checks_azure": [ "Log Analytics workspace con diagnostic setting que incluya LAQueryLogs/Audit", "Storage Account de archivo de logs con diagnostic logs StorageRead habilitados" ], "checks_gcp": [ "Data Access logs DATA_READ para logging.googleapis.com en el proyecto central de logs", "Data Access logs para storage.googleapis.com en buckets de archivo de logs" ], "evidencia": "Configuración de registro de accesos a bitácoras por nube y muestras de eventos.", "evidencia_en": "Configuration of log-access logging per cloud and sample events.", "limitaciones": "Si se usa un SIEM externo, Kyber no ve sus bitácoras de acceso propias.", "limitaciones_en": "If an external SIEM is used, Kyber cannot see its own access logs.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.15", "5.33" ], "soc2_tsc": [ "CC7.2" ], "cis_controls_v8": [ "8.2", "8.5" ] } }, { "id": 151, "numero_regla": "10.2.1.4", "requisito": "10", "seccion": "10.2", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría implementados para detección y análisis forense", "seccion_titulo_en": "Audit logs support detection of anomalies and forensic analysis", "descripcion_corta": "Registro de intentos de acceso lógico inválidos", "descripcion_larga": "Los registros de auditoría deben capturar todos los intentos de acceso lógico no válidos, ya que repetidos intentos fallidos pueden indicar ataques de fuerza bruta o adivinación de contraseñas.", "remediacion": "1) AWS: CloudTrail registra ConsoleLogin fallidos y errores AccessDenied/UnauthorizedOperation; cree filtros de métricas y alarmas para fallas de autenticación en consola y llamadas no autorizadas. 2) Azure: exporte SignInLogs (incluye fallidos) de Entra ID a Log Analytics y cree reglas analíticas en Sentinel. 3) GCP: use Cloud Audit Logs y registros de Cloud Identity/Workspace para inicios de sesión fallidos; envíelos al sink central. 4) En VMs y bases de datos, registre fallas de SSH/RDP (auth.log, Event ID 4625) y de autenticación de BD. El QSA pedirá la configuración y muestras de intentos fallidos.", "descripcion_corta_en": "Logging of invalid logical access attempts", "descripcion_larga_en": "Audit logs must capture all invalid logical access attempts, since repeated failures may indicate brute-force or password-guessing attacks.", "remediacion_en": "1) AWS: CloudTrail records failed ConsoleLogin and AccessDenied/UnauthorizedOperation errors; create metric filters and alarms for console authentication failures and unauthorized calls. 2) Azure: export Entra ID SignInLogs (including failures) to Log Analytics and create Sentinel analytics rules. 3) GCP: use Cloud Audit Logs and Cloud Identity/Workspace login logs for failed sign-ins; route them to the central sink. 4) On VMs and databases, log SSH/RDP failures (auth.log, Event ID 4625) and database authentication failures. The QSA will ask for configuration and sample failed attempts.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 244, "pagina_pdf_es": 255 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Filtro de métrica y alarma para fallas de autenticación en consola [CloudWatch.6]", "Filtro de métrica y alarma para llamadas API no autorizadas [CloudWatch.2]", "RDS del CDE exportando logs de conexión/errores a CloudWatch Logs [RDS.9]" ], "checks_azure": [ "Entra ID SignInLogs exportados a Log Analytics (falla si no existe diagnostic setting)", "Azure SQL auditoría habilitada incluyendo FAILED_DATABASE_AUTHENTICATION_GROUP" ], "checks_gcp": [ "Logs de inicio de sesión de Cloud Identity/Workspace compartidos con Cloud Logging", "Cloud SQL con log_connections y log_disconnections habilitados (PostgreSQL)" ], "evidencia": "Configuración de captura de fallos de autenticación y alarmas asociadas, con muestras de eventos.", "evidencia_en": "Configuration of authentication-failure capture and related alarms, with sample events.", "limitaciones": "Fallas de autenticación en aplicaciones propias o IdP externos no son visibles sin integración adicional.", "limitaciones_en": "Authentication failures in custom applications or external IdPs are not visible without additional integration.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.15", "8.5" ], "soc2_tsc": [ "CC7.2", "CC6.1" ], "cis_controls_v8": [ "8.2", "8.5" ] } }, { "id": 152, "numero_regla": "10.2.1.5", "requisito": "10", "seccion": "10.2", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría implementados para detección y análisis forense", "seccion_titulo_en": "Audit logs support detection of anomalies and forensic analysis", "descripcion_corta": "Registro de cambios en credenciales de identificación y autenticación", "descripcion_larga": "Los registros de auditoría deben capturar todos los cambios a credenciales de identificación y autenticación, incluyendo como mínimo la creación de cuentas nuevas, la elevación de privilegios y cualquier cambio, adición o eliminación en cuentas con acceso administrativo.", "remediacion": "1) AWS: CloudTrail captura CreateUser, CreateAccessKey, AttachUserPolicy, UpdateLoginProfile y eventos de IAM Identity Center; cree filtro de métrica y alarma para cambios de políticas IAM. 2) Azure: exporte AuditLogs de Entra ID (altas, cambios de rol, PIM) a Log Analytics y alerte sobre asignación de roles privilegiados. 3) GCP: Admin Activity logs registran SetIamPolicy, creación de cuentas de servicio y llaves; cree métricas y alertas para cambios de propiedad y roles personalizados. 4) En SO, audite cambios a /etc/passwd, /etc/shadow, sudoers y grupos locales. El QSA pedirá muestras de eventos de alta de cuentas y cambios de privilegio.", "descripcion_corta_en": "Logging of changes to identification and authentication credentials", "descripcion_larga_en": "Audit logs must capture all changes to identification and authentication credentials, including at least creation of new accounts, elevation of privileges, and every change, addition or deletion to accounts with administrative access.", "remediacion_en": "1) AWS: CloudTrail captures CreateUser, CreateAccessKey, AttachUserPolicy, UpdateLoginProfile and IAM Identity Center events; create a metric filter and alarm for IAM policy changes. 2) Azure: export Entra ID AuditLogs (account creation, role changes, PIM) to Log Analytics and alert on privileged role assignment. 3) GCP: Admin Activity logs record SetIamPolicy, service account and key creation; create log-based metrics and alerts for ownership and custom role changes. 4) At OS level, audit changes to /etc/passwd, /etc/shadow, sudoers and local groups. The QSA will ask for sample account creation and privilege change events.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 246, "pagina_pdf_es": 255 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "CloudTrail multi-región activo [CloudTrail.1]", "Filtro de métrica y alarma para cambios en políticas IAM [CloudWatch.4]", "Snapshots de EC2: reglas auditd -w /etc/passwd, /etc/shadow, /etc/sudoers presentes" ], "checks_azure": [ "Entra ID AuditLogs exportados a Log Analytics", "Alerta de Activity Log o regla de Sentinel para Microsoft.Authorization/roleAssignments/write" ], "checks_gcp": [ "Métrica basada en logs y alerta para cambios de propiedad del proyecto (SetIamPolicy con roles/owner)", "Métrica basada en logs y alerta para cambios en roles personalizados", "Snapshots de VMs: auditd vigila archivos de identidad y sudoers" ], "evidencia": "Configuración de captura y alertas de cambios de identidad por nube, más muestras de eventos.", "evidencia_en": "Configuration of identity-change capture and alerts per cloud, plus sample events.", "limitaciones": "Cambios de cuentas en aplicaciones o directorios externos no se observan sin integración.", "limitaciones_en": "Account changes in applications or external directories are not observed without integration.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.15", "5.16", "5.18" ], "soc2_tsc": [ "CC7.2", "CC6.2" ], "cis_controls_v8": [ "8.2", "8.5", "5.1" ], "banxico_spei": [ "58a. I.A.f).8" ] } }, { "id": 153, "numero_regla": "10.2.1.6", "requisito": "10", "seccion": "10.2", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría implementados para detección y análisis forense", "seccion_titulo_en": "Audit logs support detection of anomalies and forensic analysis", "descripcion_corta": "Registro de inicio, detención o pausa de los registros de auditoría", "descripcion_larga": "Los registros de auditoría deben capturar la inicialización de nuevas bitácoras y el inicio, detención o pausa de las existentes, ya que desactivar el registro es una técnica común para ocultar actividad.", "remediacion": "1) AWS: CloudTrail registra StartLogging, StopLogging, DeleteTrail y UpdateTrail; cree filtro de métrica y alarma para cambios de configuración de CloudTrail y use SCP para negar StopLogging/DeleteTrail. 2) Azure: el Activity Log registra eliminación o cambios de Diagnostic settings; cree alertas de Activity Log para esas operaciones y use Azure Policy para impedir su eliminación. 3) GCP: Admin Activity registra cambios en sinks y auditConfigs; cree métricas y alertas para cambios en la configuración de auditoría. 4) En SO, registre el estado de auditd/journald y del agente de envío. El QSA pedirá evidencia de alertas o eventos de inicio/paro de registros.", "descripcion_corta_en": "Logging of audit log initialization, starting, stopping or pausing", "descripcion_larga_en": "Audit logs must capture the initialization of new logs and the starting, stopping or pausing of existing ones, since disabling logging is a common technique to hide activity.", "remediacion_en": "1) AWS: CloudTrail records StartLogging, StopLogging, DeleteTrail and UpdateTrail; create a metric filter and alarm for CloudTrail configuration changes and use an SCP to deny StopLogging/DeleteTrail. 2) Azure: the Activity Log records deletion or changes of Diagnostic settings; create Activity Log alerts for those operations and use Azure Policy to prevent deletion. 3) GCP: Admin Activity records changes to sinks and auditConfigs; create log-based metrics and alerts for audit configuration changes. 4) At OS level, log the state of auditd/journald and the forwarding agent. The QSA will ask for evidence of alerts or start/stop logging events.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 246, "pagina_pdf_es": 256 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Filtro de métrica y alarma para cambios de configuración de CloudTrail [CloudWatch.5]", "SCP de la organización que niega cloudtrail:StopLogging y cloudtrail:DeleteTrail", "CloudTrail integrado con CloudWatch Logs [CloudTrail.5]" ], "checks_azure": [ "Alerta de Activity Log para Microsoft.Insights/diagnosticSettings/delete", "Azure Policy que despliega/impone Diagnostic settings (DeployIfNotExists) en recursos del CDE" ], "checks_gcp": [ "Métrica basada en logs y alerta para cambios en la configuración de auditoría (SetIamPolicy con auditConfigDeltas)", "Alerta para eliminación o modificación de sinks (DeleteSink/UpdateSink)" ], "evidencia": "Alarmas configuradas para eventos de paro/modificación del registro y muestra de eventos.", "evidencia_en": "Alarms configured for logging stop/modification events and sample events.", "limitaciones": "No se detectan pausas del agente de logs en VMs si el agente no reporta su estado a la nube.", "limitaciones_en": "Pauses of the log agent on VMs are not detected unless the agent reports its status to the cloud.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.15", "8.16" ], "soc2_tsc": [ "CC7.2" ], "cis_controls_v8": [ "8.2", "8.5" ] } }, { "id": 154, "numero_regla": "10.2.1.7", "requisito": "10", "seccion": "10.2", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría implementados para detección y análisis forense", "seccion_titulo_en": "Audit logs support detection of anomalies and forensic analysis", "descripcion_corta": "Registro de creación y eliminación de objetos a nivel de sistema", "descripcion_larga": "Los registros de auditoría deben capturar la creación y eliminación de objetos a nivel de sistema, como binarios, servicios, tareas o componentes que pueden usarse para instalar software malicioso.", "remediacion": "1) AWS: CloudTrail con eventos de administración de escritura y AWS Config para registrar creación y eliminación de instancias, funciones Lambda, roles, imágenes y otros recursos. 2) Azure: Activity Log (operaciones write/delete) y Change Analysis enviados a Log Analytics. 3) GCP: Admin Activity logs y Cloud Asset Inventory con feeds de cambios. 4) En SO, configure auditd/Sysmon para registrar creación y borrado de binarios, servicios, tareas programadas y módulos del kernel. El QSA pedirá muestras de eventos de creación y eliminación.", "descripcion_corta_en": "Logging of creation and deletion of system-level objects", "descripcion_larga_en": "Audit logs must capture the creation and deletion of system-level objects, such as binaries, services, jobs or components that could be used to install malicious software.", "remediacion_en": "1) AWS: CloudTrail with write management events and AWS Config to record creation and deletion of instances, Lambda functions, roles, images and other resources. 2) Azure: Activity Log (write/delete operations) and Change Analysis sent to Log Analytics. 3) GCP: Admin Activity logs and Cloud Asset Inventory with change feeds. 4) At OS level, configure auditd/Sysmon to log creation and deletion of binaries, services, scheduled tasks and kernel modules. The QSA will ask for sample creation and deletion events.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 247, "pagina_pdf_es": 256 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "CloudTrail multi-región con eventos de escritura [CloudTrail.1]", "AWS Config recorder registrando todos los tipos de recursos [Config.1]", "Snapshots de EC2: reglas auditd para init_module/delete_module y directorios de binarios del sistema" ], "checks_azure": [ "Activity Log exportado a Log Analytics", "Snapshots de VMs Windows: Sysmon o auditoría de creación de servicios (Event ID 7045) configurada" ], "checks_gcp": [ "Admin Activity logs enrutados al sink central", "Cloud Asset Inventory con feed de cambios hacia Pub/Sub", "Snapshots de VMs: auditd para módulos del kernel y binarios del sistema" ], "evidencia": "Configuración de CloudTrail/Config/Activity Log/Asset Inventory y reglas de auditoría de SO.", "evidencia_en": "CloudTrail/Config/Activity Log/Asset Inventory configuration and OS audit rules.", "limitaciones": "La creación de objetos dentro de contenedores o aplicaciones no se observa sin agente o registros de runtime.", "limitaciones_en": "Object creation inside containers or applications is not observed without an agent or runtime logs.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.15", "8.9" ], "soc2_tsc": [ "CC7.2", "CC8.1" ], "cis_controls_v8": [ "8.2", "8.5" ] } }, { "id": 155, "numero_regla": "10.2.2", "requisito": "10", "seccion": "10.2", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría implementados para detección y análisis forense", "seccion_titulo_en": "Audit logs support detection of anomalies and forensic analysis", "descripcion_corta": "Detalles mínimos registrados por cada evento auditable", "descripcion_larga": "Para cada evento auditable, los registros deben incluir: identificación del usuario, tipo de evento, fecha y hora, indicación de éxito o falla, origen del evento, e identidad o nombre de los datos, componente del sistema, recurso o servicio afectado (por ejemplo, nombre y protocolo).", "remediacion": "1) Use fuentes nativas que ya incluyen estos campos: CloudTrail (userIdentity, eventName, eventTime, errorCode, sourceIPAddress, resources), Azure Activity/Entra logs (caller, operationName, time, status, callerIpAddress, resourceId) y Cloud Audit Logs (principalEmail, methodName, timestamp, status, callerIp, resourceName). 2) Para logs de SO y aplicación, defina un formato estructurado (JSON) con los seis campos y valídelo en la ingesta. 3) Evite cuentas compartidas para que el usuario sea identificable. 4) Revise muestras trimestralmente. El QSA pedirá muestras de eventos de cada tipo de fuente mostrando todos los campos.", "descripcion_corta_en": "Minimum details recorded for each auditable event", "descripcion_larga_en": "For each auditable event, logs must include: user identification, event type, date and time, success or failure indication, event origin, and the identity or name of the affected data, system component, resource or service (for example, name and protocol).", "remediacion_en": "1) Use native sources that already include these fields: CloudTrail (userIdentity, eventName, eventTime, errorCode, sourceIPAddress, resources), Azure Activity/Entra logs (caller, operationName, time, status, callerIpAddress, resourceId) and Cloud Audit Logs (principalEmail, methodName, timestamp, status, callerIp, resourceName). 2) For OS and application logs, define a structured (JSON) format with the six fields and validate it at ingestion. 3) Avoid shared accounts so the user is identifiable. 4) Review samples quarterly. The QSA will ask for sample events from each source type showing all fields.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 247, "pagina_pdf_es": 257 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "CloudTrail habilitado como fuente primaria (incluye userIdentity, eventTime, errorCode, sourceIPAddress) [CloudTrail.1]", "VPC Flow Logs con formato que incluye srcaddr, dstaddr, dstport, protocol, action y start [EC2.6]" ], "checks_azure": [ "Activity Log y Entra ID logs en Log Analytics (campos Caller, OperationName, ResultType, CallerIpAddress)", "NSG/VNet flow logs habilitados" ], "checks_gcp": [ "Cloud Audit Logs Admin y Data Access habilitados (authenticationInfo, methodName, status, requestMetadata.callerIp)", "VPC flow logs con metadata incluida (metadata = INCLUDE_ALL_METADATA)" ], "evidencia": "Muestras de eventos por tipo de fuente generadas por Kyber mostrando los campos requeridos.", "evidencia_en": "Kyber-generated sample events per source type showing required fields.", "limitaciones": "Kyber no valida el contenido de logs de aplicación o SO que no se ingesten en servicios nativos de la nube.", "limitaciones_en": "Kyber does not validate the content of application or OS logs that are not ingested into native cloud services.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.15" ], "soc2_tsc": [ "CC7.2" ], "cis_controls_v8": [ "8.5" ], "banxico_spei": [ "58a. I.A.d).3" ] } }, { "id": 156, "numero_regla": "10.3.1", "requisito": "10", "seccion": "10.3", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría protegidos contra destrucción y modificación", "seccion_titulo_en": "Audit logs are protected from destruction and unauthorized modification", "descripcion_corta": "Acceso de lectura a registros de auditoría limitado por necesidad laboral", "descripcion_larga": "El acceso de lectura a los archivos de registros de auditoría debe limitarse a quienes lo requieren por sus funciones, porque las bitácoras pueden contener información sensible y revelar detalles útiles para un atacante.", "remediacion": "1) Centralice las bitácoras en una cuenta/suscripción/proyecto dedicado de log archive. 2) AWS: restrinja con políticas de bucket y de llave KMS quién puede leer el bucket de CloudTrail y los grupos de CloudWatch Logs; bloquee acceso público. 3) Azure: use RBAC con alcance al espacio de Log Analytics o a nivel de tabla y limite Log Analytics Reader. 4) GCP: limite roles/logging.viewer y roles/logging.privateLogViewer a grupos designados y restrinja los buckets de logs. 5) Revise los permisos trimestralmente. El QSA pedirá la lista de identidades con acceso de lectura y su justificación.", "descripcion_corta_en": "Read access to audit logs limited to job-related need", "descripcion_larga_en": "Read access to audit log files must be limited to those whose job requires it, because logs can contain sensitive information and reveal details useful to an attacker.", "remediacion_en": "1) Centralize logs in a dedicated log archive account/subscription/project. 2) AWS: restrict via bucket and KMS key policies who can read the CloudTrail bucket and CloudWatch Logs groups; block public access. 3) Azure: use workspace- or table-scoped RBAC and limit Log Analytics Reader. 4) GCP: limit roles/logging.viewer and roles/logging.privateLogViewer to designated groups and restrict log buckets. 5) Review permissions quarterly. The QSA will ask for the list of identities with read access and their justification.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 248, "pagina_pdf_es": 258 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Bucket S3 de CloudTrail no accesible públicamente [CloudTrail.6]", "Block Public Access habilitado a nivel de cuenta/bucket [S3.1] [S3.8]", "CloudTrail cifrado con KMS y política de llave que restringe kms:Decrypt [CloudTrail.2]", "Principales IAM con s3:GetObject o logs:GetLogEvents sobre recursos de bitácoras (lista para revisión)" ], "checks_azure": [ "Asignaciones de rol sobre el workspace de Log Analytics y la cuenta de archivo (lista para revisión)", "Storage Account de logs con allowBlobPublicAccess = false" ], "checks_gcp": [ "Bindings IAM con roles/logging.viewer o roles/logging.privateLogViewer (lista para revisión)", "Buckets de Cloud Storage de logs con uniform bucket-level access y sin allUsers/allAuthenticatedUsers" ], "evidencia": "Listado de identidades con acceso de lectura a bitácoras por nube y configuración de acceso público.", "evidencia_en": "List of identities with read access to logs per cloud and public access configuration.", "limitaciones": "Kyber no determina si cada acceso está justificado por la función laboral; requiere revisión del cliente.", "limitaciones_en": "Kyber cannot determine whether each access is justified by job function; customer review is required.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.15", "5.15", "8.3" ], "soc2_tsc": [ "CC6.1", "CC6.3" ], "cis_controls_v8": [ "3.3", "6.8" ], "banxico_spei": [ "58a. I.B.e)" ] } }, { "id": 157, "numero_regla": "10.3.2", "requisito": "10", "seccion": "10.3", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría protegidos contra destrucción y modificación", "seccion_titulo_en": "Audit logs are protected from destruction and unauthorized modification", "descripcion_corta": "Archivos de registros de auditoría protegidos contra modificación", "descripcion_larga": "Los archivos de registros de auditoría deben estar protegidos para evitar que las personas los modifiquen, de manera que un atacante no pueda alterar o borrar evidencia de su actividad.", "remediacion": "1) AWS: almacene CloudTrail en un bucket de una cuenta de log archive con S3 Object Lock (modo compliance), versionado y MFA delete; niegue s3:DeleteObject y PutBucketPolicy con SCP, y cifre con KMS. 2) Azure: use almacenamiento con política de inmutabilidad (time-based retention bloqueada) para el archivo de logs y restrinja permisos de purga en Log Analytics. 3) GCP: use buckets de Cloud Logging con retención bloqueada y buckets de Cloud Storage con Bucket Lock. 4) Separe funciones: los administradores del CDE no deben administrar la cuenta de bitácoras. El QSA pedirá la configuración de inmutabilidad y permisos.", "descripcion_corta_en": "Audit log files protected against modification", "descripcion_larga_en": "Audit log files must be protected to prevent individuals from modifying them, so that an attacker cannot alter or erase evidence of their activity.", "remediacion_en": "1) AWS: store CloudTrail in a log archive account bucket with S3 Object Lock (compliance mode), versioning and MFA delete; deny s3:DeleteObject and PutBucketPolicy via SCP and encrypt with KMS. 2) Azure: use storage with a locked time-based immutability policy for the log archive and restrict purge permissions in Log Analytics. 3) GCP: use Cloud Logging buckets with locked retention and Cloud Storage buckets with Bucket Lock. 4) Separate duties: CDE administrators must not administer the logging account. The QSA will ask for immutability and permission configuration.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 249, "pagina_pdf_es": 258 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Bucket de CloudTrail con Object Lock habilitado [S3.15]", "Bucket de CloudTrail con MFA delete habilitado [S3.20]", "Bucket de CloudTrail con versionado habilitado", "CloudTrail cifrado con KMS [CloudTrail.2]" ], "checks_azure": [ "Contenedor de archivo de logs con immutabilityPolicy en estado Locked", "Storage Account de logs con soft delete de blobs habilitado", "Asignaciones con permiso Microsoft.OperationalInsights/workspaces/purge/action limitadas" ], "checks_gcp": [ "Buckets de Cloud Logging con locked = true en la retención", "Buckets de Cloud Storage de archivo de logs con retentionPolicy.isLocked = true", "Cuentas con roles/logging.bucketWriter o logging.admin en el proyecto de logs limitadas" ], "evidencia": "Configuración de inmutabilidad, versionado, cifrado y permisos de escritura/borrado del almacenamiento de bitácoras.", "evidencia_en": "Immutability, versioning, encryption and write/delete permission configuration of log storage.", "limitaciones": "No cubre bitácoras locales en VMs antes de su envío ni SIEM de terceros.", "limitaciones_en": "Does not cover local logs on VMs before shipping or third-party SIEMs.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.15", "5.33" ], "soc2_tsc": [ "CC7.2", "CC6.1" ], "cis_controls_v8": [ "8.3", "3.11" ], "banxico_spei": [ "58a. I.A.d).4", "58a. I.B.e)" ] } }, { "id": 158, "numero_regla": "10.3.3", "requisito": "10", "seccion": "10.3", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría protegidos contra destrucción y modificación", "seccion_titulo_en": "Audit logs are protected from destruction and unauthorized modification", "descripcion_corta": "Respaldo oportuno de bitácoras a servidor central seguro o medio difícil de modificar", "descripcion_larga": "Los archivos de registros de auditoría, incluidos los de tecnologías expuestas a Internet, deben respaldarse oportunamente en uno o varios servidores de bitácoras centrales, internos y seguros, o en otro medio difícil de modificar.", "remediacion": "1) AWS: use un trail de organización que entregue a un bucket central en la cuenta de log archive; envíe logs de ELB, CloudFront, WAF y Flow Logs a ese mismo destino o a CloudWatch Logs con suscripción a un repositorio central. 2) Azure: dirija Diagnostic settings de todas las suscripciones a un Log Analytics central y/o a una cuenta de almacenamiento inmutable. 3) GCP: configure un sink agregado a nivel organización hacia un bucket de Cloud Logging o Cloud Storage con Bucket Lock. 4) En VMs, use agentes (CloudWatch agent, Azure Monitor Agent, Ops Agent) con envío casi en tiempo real. El QSA pedirá la arquitectura de centralización y la configuración de los destinos.", "descripcion_corta_en": "Timely backup of audit logs to a secure central server or hard-to-modify media", "descripcion_larga_en": "Audit log files, including those of Internet-facing technologies, must be promptly backed up to one or more secure, central, internal log servers or to other media that is hard to modify.", "remediacion_en": "1) AWS: use an organization trail delivering to a central bucket in the log archive account; send ELB, CloudFront, WAF and Flow Logs to that same destination or to CloudWatch Logs with a subscription to a central repository. 2) Azure: point Diagnostic settings from all subscriptions to a central Log Analytics workspace and/or an immutable storage account. 3) GCP: configure an organization aggregated sink to a Cloud Logging bucket or Cloud Storage bucket with Bucket Lock. 4) On VMs, use agents (CloudWatch agent, Azure Monitor Agent, Ops Agent) with near-real-time shipping. The QSA will ask for the centralization architecture and destination configuration.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 249, "pagina_pdf_es": 259 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "CloudTrail de organización (IsOrganizationTrail = true) entregando a bucket en cuenta dedicada", "CloudTrail integrado con CloudWatch Logs [CloudTrail.5]", "Logs de ELB/CloudFront/WAF con destino configurado [ELB.5] [CloudFront.5] [WAF.11]", "Instancias EC2 del CDE con agente de CloudWatch configurado (snapshots o SSM inventory)" ], "checks_azure": [ "Diagnostic settings de todas las suscripciones apuntando al workspace central", "Application Gateway/Front Door/Firewall con diagnostic logs al destino central", "VMs del CDE con Azure Monitor Agent y Data Collection Rule asociada" ], "checks_gcp": [ "Sink agregado de organización (includeChildren = true) hacia destino central", "Load balancers HTTP(S) con logging habilitado", "VMs del CDE con Ops Agent instalado" ], "evidencia": "Diagrama/listado de destinos centrales de bitácoras y configuración de envío por fuente.", "evidencia_en": "Diagram/listing of central log destinations and per-source shipping configuration.", "limitaciones": "No puede confirmar la latencia real de entrega ni bitácoras de dispositivos fuera de la nube.", "limitaciones_en": "Cannot confirm actual delivery latency or logs from devices outside the cloud.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.15", "8.13" ], "soc2_tsc": [ "CC7.2", "A1.2" ], "cis_controls_v8": [ "8.9", "8.3" ] } }, { "id": 159, "numero_regla": "10.3.4", "requisito": "10", "seccion": "10.3", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría protegidos contra destrucción y modificación", "seccion_titulo_en": "Audit logs are protected from destruction and unauthorized modification", "descripcion_corta": "Monitoreo de integridad o detección de cambios en registros de auditoría", "descripcion_larga": "Se deben usar mecanismos de monitoreo de integridad de archivos o de detección de cambios sobre los registros de auditoría, de modo que cualquier modificación de datos de bitácora existentes genere una alerta.", "remediacion": "1) AWS: habilite la validación de integridad de archivos de log de CloudTrail (digest firmados) y valide periódicamente con aws cloudtrail validate-logs; combine con Object Lock. 2) Alerte vía EventBridge/CloudWatch ante PutObject/DeleteObject en el bucket de bitácoras por principales distintos de CloudTrail. 3) Azure: use almacenamiento inmutable y alertas de Activity Log/Sentinel ante cambios o purgas en el almacenamiento de logs. 4) GCP: use Bucket Lock y alertas sobre operaciones de escritura/borrado en buckets de logs. 5) Para logs en VMs, aplique FIM (p. ej. AIDE, Defender for Servers FIM) sobre directorios de bitácoras. El QSA pedirá la configuración y ejemplos de alertas.", "descripcion_corta_en": "File integrity monitoring or change detection on audit logs", "descripcion_larga_en": "File integrity monitoring or change-detection mechanisms must be applied to audit logs so that any modification of existing log data raises an alert.", "remediacion_en": "1) AWS: enable CloudTrail log file integrity validation (signed digests) and periodically verify with aws cloudtrail validate-logs; combine with Object Lock. 2) Alert via EventBridge/CloudWatch on PutObject/DeleteObject in the log bucket by principals other than CloudTrail. 3) Azure: use immutable storage and Activity Log/Sentinel alerts on changes or purges of log storage. 4) GCP: use Bucket Lock and alerts on write/delete operations on log buckets. 5) For logs on VMs, apply FIM (e.g., AIDE, Defender for Servers FIM) on log directories. The QSA will ask for the configuration and sample alerts.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 250, "pagina_pdf_es": 259 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "CloudTrail con validación de integridad de archivos de log habilitada [CloudTrail.4]", "Bucket de CloudTrail con Object Lock [S3.15]", "Regla de EventBridge/alarma ante DeleteObject o PutBucketPolicy en el bucket de bitácoras" ], "checks_azure": [ "Contenedores de logs con política de inmutabilidad bloqueada", "Defender for Servers con File Integrity Monitoring habilitado en VMs del CDE", "Alerta para operaciones de purga en Log Analytics" ], "checks_gcp": [ "Buckets de logs con Bucket Lock / retención bloqueada", "Métrica basada en logs y alerta ante storage.objects.delete en buckets de archivo de logs" ], "evidencia": "Configuración de validación de integridad, inmutabilidad y alertas sobre cambios en bitácoras.", "evidencia_en": "Integrity validation, immutability and change-alert configuration on logs.", "limitaciones": "Kyber no ejecuta la validación criptográfica de cada digest ni verifica FIM en bitácoras locales de VMs fuera de lo visible en snapshots.", "limitaciones_en": "Kyber does not run cryptographic validation of every digest nor verify FIM on local VM logs beyond what is visible in snapshots.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.15", "8.16" ], "soc2_tsc": [ "CC7.2", "CC7.1" ], "cis_controls_v8": [ "8.3" ] } }, { "id": 160, "numero_regla": "10.4.1", "requisito": "10", "seccion": "10.4", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría revisados para identificar anomalías", "seccion_titulo_en": "Audit logs are reviewed to identify anomalies or suspicious activity", "descripcion_corta": "Revisión diaria de eventos de seguridad y bitácoras de componentes críticos", "descripcion_larga": "Deben revisarse al menos una vez al día: todos los eventos de seguridad; las bitácoras de todos los componentes que almacenan, procesan o transmiten datos del titular de la tarjeta (CHD) o datos de autenticación confidenciales (SAD); las de todos los componentes críticos; y las de servidores y componentes que cumplen funciones de seguridad, como controles de seguridad de la red (NSC), IDS/IPS y servidores de autenticación.", "remediacion": "1) AWS: habilite GuardDuty en todas las regiones y cuentas, Security Hub con el estándar PCI DSS v4.0.1 y Detective para investigación; centralice hallazgos en una cuenta administradora. 2) Azure: habilite Microsoft Defender for Cloud (planes del CDE) y Microsoft Sentinel con conectores de Activity Log, Entra ID, NSG y Defender. 3) GCP: active Security Command Center (Premium/Enterprise) y, si aplica, Google SecOps (Chronicle). 4) Defina un procedimiento de revisión diaria con responsable, registre la revisión (ticket o firma en el SIEM) y escale hallazgos. El QSA pedirá evidencia diaria de revisión de un periodo muestral.", "descripcion_corta_en": "Daily review of security events and critical component logs", "descripcion_larga_en": "At least once daily the following must be reviewed: all security events; logs of all components that store, process or transmit cardholder data (CHD) or sensitive authentication data (SAD); logs of all critical components; and logs of servers and components performing security functions, such as network security controls (NSCs), IDS/IPS and authentication servers.", "remediacion_en": "1) AWS: enable GuardDuty in all regions and accounts, Security Hub with the PCI DSS v4.0.1 standard and Detective for investigation; centralize findings in an administrator account. 2) Azure: enable Microsoft Defender for Cloud (CDE plans) and Microsoft Sentinel with Activity Log, Entra ID, NSG and Defender connectors. 3) GCP: enable Security Command Center (Premium/Enterprise) and, if applicable, Google SecOps (Chronicle). 4) Define a daily review procedure with an owner, record the review (ticket or SIEM sign-off) and escalate findings. The QSA will ask for evidence of daily review for a sample period.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 251, "pagina_pdf_es": 260 }, "kyber_cobertura": { "tipo": "deteccion_presencia", "automatizacion": "media", "checks_aws": [ "GuardDuty habilitado en todas las regiones y cuentas [GuardDuty.1]", "Security Hub habilitado con estándar PCI DSS v4.0.1 en todas las regiones", "Agregación de hallazgos de Security Hub en cuenta administradora delegada" ], "checks_azure": [ "Defender for Cloud: planes Defender for Servers, SQL, Storage y Key Vault en estado Standard", "Microsoft Sentinel habilitado en el workspace central con conectores activos" ], "checks_gcp": [ "Security Command Center activado a nivel organización (tier Premium/Enterprise)", "Event Threat Detection habilitado en SCC" ], "evidencia": "Estado de habilitación de servicios de detección y agregación, más registros de revisión diaria cargados por el cliente.", "evidencia_en": "Enablement status of detection and aggregation services, plus daily review records uploaded by the customer.", "limitaciones": "Kyber verifica que las herramientas existan y estén activas, no que la revisión diaria se realice ni su calidad.", "limitaciones_en": "Kyber verifies that tools exist and are active, not that daily review is performed or its quality.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.15", "8.16" ], "soc2_tsc": [ "CC7.2", "CC7.3" ], "cis_controls_v8": [ "8.11", "13.1" ] }, "mapeo_ucf": [ { "clave": "UCF-LOG-002", "relacion": "equivalent", "cobertura_pct": 80 } ] }, { "id": 161, "numero_regla": "10.4.1.1", "requisito": "10", "seccion": "10.4", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría revisados para identificar anomalías", "seccion_titulo_en": "Audit logs are reviewed to identify anomalies or suspicious activity", "descripcion_corta": "Uso de mecanismos automatizados para revisar registros de auditoría", "descripcion_larga": "Deben utilizarse mecanismos automatizados para realizar las revisiones de registros de auditoría, ya que la revisión manual de grandes volúmenes es propensa a errores y lenta para identificar actividad sospechosa.", "remediacion": "1) AWS: use GuardDuty, Security Hub (controles automáticos y hallazgos consolidados) y reglas de EventBridge/CloudWatch Alarms con notificación por SNS; considere Detective o un SIEM para correlación. 2) Azure: use reglas analíticas programadas y NRT en Microsoft Sentinel y alertas de Defender for Cloud con automatizaciones (Logic Apps). 3) GCP: use Security Command Center, alertas basadas en logs de Cloud Monitoring y reglas de detección en Google SecOps. 4) Documente qué casos de uso cubre cada regla y quién recibe las alertas. El QSA pedirá la lista de reglas activas y evidencia de alertas generadas.", "descripcion_corta_en": "Automated mechanisms used to review audit logs", "descripcion_larga_en": "Automated mechanisms must be used to perform audit log reviews, since manual review of large volumes is error-prone and slow at identifying suspicious activity.", "remediacion_en": "1) AWS: use GuardDuty, Security Hub (automated controls and consolidated findings) and EventBridge/CloudWatch Alarm rules with SNS notification; consider Detective or a SIEM for correlation. 2) Azure: use scheduled and NRT analytics rules in Microsoft Sentinel and Defender for Cloud alerts with automations (Logic Apps). 3) GCP: use Security Command Center, Cloud Monitoring log-based alerts and detection rules in Google SecOps. 4) Document which use cases each rule covers and who receives alerts. The QSA will ask for the list of active rules and evidence of generated alerts.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 252, "pagina_pdf_es": 262 }, "kyber_cobertura": { "tipo": "deteccion_presencia", "automatizacion": "media", "checks_aws": [ "GuardDuty habilitado [GuardDuty.1]", "Reglas de EventBridge que envían hallazgos de GuardDuty/Security Hub a SNS u otro destino", "Alarmas de CloudWatch con acción SNS configurada para filtros de métricas de seguridad" ], "checks_azure": [ "Microsoft Sentinel con reglas analíticas habilitadas (falla si 0 reglas activas)", "Defender for Cloud con notificaciones por correo/automatización de alertas configuradas" ], "checks_gcp": [ "Security Command Center con notificaciones (notificationConfigs) hacia Pub/Sub", "Políticas de alerta de Cloud Monitoring con canales de notificación configurados" ], "evidencia": "Inventario de reglas y alarmas automatizadas activas y sus destinos de notificación.", "evidencia_en": "Inventory of active automated rules and alarms and their notification destinations.", "limitaciones": "Kyber no evalúa la eficacia de las reglas ni la cobertura de casos de uso.", "limitaciones_en": "Kyber does not evaluate rule effectiveness or use-case coverage.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.16" ], "soc2_tsc": [ "CC7.2" ], "cis_controls_v8": [ "8.11", "13.1" ], "banxico_spei": [ "58a. I.A.b).5 bis" ] } }, { "id": 162, "numero_regla": "10.4.2", "requisito": "10", "seccion": "10.4", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría revisados para identificar anomalías", "seccion_titulo_en": "Audit logs are reviewed to identify anomalies or suspicious activity", "descripcion_corta": "Revisión periódica de bitácoras de los demás componentes del sistema", "descripcion_larga": "Las bitácoras de todos los demás componentes del sistema que no estén cubiertos por la revisión diaria del 10.4.1 deben revisarse periódicamente. Aplica a todos los demás componentes dentro del alcance.", "remediacion": "1) Inventaríe los componentes del alcance que no son críticos ni manejan CHD/SAD (p. ej. herramientas internas, entornos de soporte). 2) Asigne una frecuencia de revisión basada en el análisis de riesgos del 10.4.2.1. 3) Incluya sus bitácoras en el SIEM (Sentinel, Security Hub/OpenSearch, SCC/Chronicle) con reglas o reportes periódicos. 4) Registre cada revisión con fecha y responsable. El QSA pedirá la lista de componentes, la frecuencia definida y evidencia de revisiones.", "descripcion_corta_en": "Periodic review of logs for all other system components", "descripcion_larga_en": "Logs of all other system components not covered by the daily review in 10.4.1 must be reviewed periodically. This applies to all other in-scope components.", "remediacion_en": "1) Inventory in-scope components that are not critical and do not handle CHD/SAD (e.g., internal tools, support environments). 2) Assign a review frequency based on the 10.4.2.1 risk analysis. 3) Bring their logs into the SIEM (Sentinel, Security Hub/OpenSearch, SCC/Chronicle) with periodic rules or reports. 4) Record each review with date and owner. The QSA will ask for the component list, the defined frequency and review evidence.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 253, "pagina_pdf_es": 263 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Inventario de componentes sujetos a revisión periódica (Kyber puede generarlo) y registros de revisión cargados por el cliente.", "evidencia_en": "Inventory of components subject to periodic review (Kyber can generate it) and review records uploaded by the customer.", "limitaciones": "Kyber no puede confirmar que las revisiones periódicas ocurran.", "limitaciones_en": "Kyber cannot confirm that periodic reviews occur.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.15", "8.16" ], "soc2_tsc": [ "CC7.2" ], "cis_controls_v8": [ "8.11" ] } }, { "id": 163, "numero_regla": "10.4.2.1", "requisito": "10", "seccion": "10.4", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría revisados para identificar anomalías", "seccion_titulo_en": "Audit logs are reviewed to identify anomalies or suspicious activity", "descripcion_corta": "Frecuencia de revisión periódica de bitácoras definida por análisis de riesgos dirigido", "descripcion_larga": "La frecuencia con la que se revisan las bitácoras de los demás componentes (10.4.2) debe establecerse mediante el análisis de riesgos dirigido de la entidad, realizado conforme a todos los elementos del Requisito 12.3.1.", "remediacion": "1) Realice un análisis de riesgos dirigido (plantilla del Requisito 12.3.1) para los componentes del 10.4.2: activos, amenazas, probabilidad, impacto y frecuencia justificada. 2) Documente la frecuencia resultante (p. ej. semanal) por tipo de componente. 3) Revise el análisis al menos cada 12 meses o tras cambios de arquitectura en la nube. 4) Alinee los reportes programados del SIEM con esa frecuencia. El QSA pedirá el análisis de riesgos aprobado y evidencia de que la frecuencia se cumple.", "descripcion_corta_en": "Periodic log review frequency defined by targeted risk analysis", "descripcion_larga_en": "The frequency of reviewing logs for other components (10.4.2) must be set through the entity's targeted risk analysis, performed according to all elements of Requirement 12.3.1.", "remediacion_en": "1) Perform a targeted risk analysis (Requirement 12.3.1 template) for the 10.4.2 components: assets, threats, likelihood, impact and justified frequency. 2) Document the resulting frequency (e.g., weekly) per component type. 3) Review the analysis at least every 12 months or after cloud architecture changes. 4) Align scheduled SIEM reports with that frequency. The QSA will ask for the approved risk analysis and evidence that the frequency is met.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 254, "pagina_pdf_es": 264 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Análisis de riesgos dirigido aprobado (plantilla de Kyber) con la frecuencia definida.", "evidencia_en": "Approved targeted risk analysis (Kyber template) with the defined frequency.", "limitaciones": "Kyber no evalúa la calidad del análisis de riesgos.", "limitaciones_en": "Kyber does not evaluate the quality of the risk analysis.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.7", "8.16" ], "soc2_tsc": [ "CC3.2", "CC7.2" ], "cis_controls_v8": [ "8.11" ] } }, { "id": 164, "numero_regla": "10.4.3", "requisito": "10", "seccion": "10.4", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Registros de auditoría revisados para identificar anomalías", "seccion_titulo_en": "Audit logs are reviewed to identify anomalies or suspicious activity", "descripcion_corta": "Atención de excepciones y anomalías detectadas en la revisión de bitácoras", "descripcion_larga": "Las excepciones y anomalías identificadas durante la revisión de registros deben atenderse, es decir, investigarse y resolverse, para que la revisión tenga efecto real.", "remediacion": "1) Integre los hallazgos de GuardDuty/Security Hub, Defender for Cloud/Sentinel o Security Command Center con un sistema de tickets o con el proceso de respuesta a incidentes. 2) Defina SLA por severidad (p. ej. crítico 24 h, alto 7 días) y estados de flujo (NEW, NOTIFIED, RESOLVED / Active, Dismissed). 3) Documente la investigación, la causa y la acción tomada en cada excepción. 4) Revise mensualmente hallazgos abiertos fuera de SLA. El QSA pedirá muestras de alertas con su ticket y resolución.", "descripcion_corta_en": "Exceptions and anomalies found during log review are addressed", "descripcion_larga_en": "Exceptions and anomalies identified during log review must be addressed, that is, investigated and resolved, so that the review has real effect.", "remediacion_en": "1) Integrate GuardDuty/Security Hub, Defender for Cloud/Sentinel or Security Command Center findings with a ticketing system or the incident response process. 2) Define SLAs by severity (e.g., critical 24 h, high 7 days) and workflow states (NEW, NOTIFIED, RESOLVED / Active, Dismissed). 3) Document the investigation, cause and action taken for each exception. 4) Review open findings beyond SLA monthly. The QSA will ask for sample alerts with their ticket and resolution.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 255, "pagina_pdf_es": 265 }, "kyber_cobertura": { "tipo": "deteccion_presencia", "automatizacion": "media", "checks_aws": [ "Hallazgos de Security Hub CRITICAL/HIGH con Workflow.Status = NEW por más de 30 días (falla si existen)", "Hallazgos de GuardDuty de severidad alta no archivados por más de 30 días" ], "checks_azure": [ "Alertas de Defender for Cloud de severidad alta en estado Active por más de 30 días", "Incidentes de Sentinel sin propietario asignado o en estado New por más de 7 días" ], "checks_gcp": [ "Hallazgos de Security Command Center HIGH/CRITICAL en estado ACTIVE por más de 30 días" ], "evidencia": "Reporte de antigüedad de hallazgos abiertos por severidad, más tickets de resolución cargados por el cliente.", "evidencia_en": "Aging report of open findings by severity, plus resolution tickets uploaded by the customer.", "limitaciones": "Kyber no puede valorar si la investigación fue adecuada ni ver tickets en sistemas externos.", "limitaciones_en": "Kyber cannot judge whether investigations were adequate nor see tickets in external systems.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.25", "5.26", "8.16" ], "soc2_tsc": [ "CC7.3", "CC7.4" ], "cis_controls_v8": [ "8.11", "17.4" ] } }, { "id": 165, "numero_regla": "10.5.1", "requisito": "10", "seccion": "10.5", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Historial de registros de auditoría conservado y disponible", "seccion_titulo_en": "Audit log history is retained and available for analysis", "descripcion_corta": "Retención de bitácoras de 12 meses con 3 meses disponibles de inmediato", "descripcion_larga": "El historial de registros de auditoría debe conservarse al menos 12 meses, y como mínimo los tres meses más recientes deben estar disponibles de inmediato para análisis.", "remediacion": "1) AWS: configure la retención de grupos de CloudWatch Logs del CDE en 365 días o más (o mínimo 90 días con exportación a S3) y reglas de ciclo de vida en el bucket de CloudTrail/Flow Logs que no expiren objetos antes de 365 días (transición a Glacier después de 90 días permitida). 2) Azure: retención interactiva de Log Analytics de 90 días o más y retención total (archivo) de 365 días o más, o exportación a almacenamiento inmutable. 3) GCP: buckets de Cloud Logging con retentionDays ≥ 365 (el bucket _Default trae 30 días) o sink a Cloud Storage con retención bloqueada. 4) Pruebe la recuperación de bitácoras de 6 a 12 meses de antigüedad. El QSA pedirá la configuración de retención y una muestra de logs antiguos.", "descripcion_corta_en": "Audit log retention of 12 months with 3 months immediately available", "descripcion_larga_en": "Audit log history must be kept for at least 12 months, with at least the most recent three months immediately available for analysis.", "remediacion_en": "1) AWS: set CDE CloudWatch Logs group retention to 365 days or more (or at least 90 days with export to S3) and lifecycle rules on the CloudTrail/Flow Logs bucket that do not expire objects before 365 days (transition to Glacier after 90 days is acceptable). 2) Azure: Log Analytics interactive retention of 90 days or more and total (archive) retention of 365 days or more, or export to immutable storage. 3) GCP: Cloud Logging buckets with retentionDays ≥ 365 (the _Default bucket ships with 30 days) or a sink to Cloud Storage with locked retention. 4) Test retrieval of logs that are 6 to 12 months old. The QSA will ask for the retention configuration and a sample of older logs.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 256, "pagina_pdf_es": 266 }, "kyber_cobertura": { "tipo": "retencion_medible", "automatizacion": "alta", "checks_aws": [ "CloudWatch Logs: grupos del CDE con retentionInDays ≥ 365 o sin expiración [CloudWatch.16]", "S3 bucket de CloudTrail/Flow Logs: reglas de lifecycle sin Expiration < 365 días", "Grupos de CloudWatch Logs con retención < 90 días sin exportación a S3 (falla si existen)", "Object Lock con retención por defecto ≥ 365 días en bucket de bitácoras" ], "checks_azure": [ "Log Analytics workspace: retentionInDays ≥ 90 (interactiva)", "Log Analytics: totalRetentionInDays ≥ 365 por tabla o exportación a Storage con inmutabilidad ≥ 365 días", "Storage Account de archivo: lifecycle management sin borrado < 365 días" ], "checks_gcp": [ "Buckets de Cloud Logging del CDE con retentionDays ≥ 365 (falla si _Default queda en 30 días sin otro sink)", "Bucket de Cloud Storage destino de sinks con retentionPolicy ≥ 365 días", "Lifecycle de buckets de logs sin regla Delete con age < 365" ], "evidencia": "Reporte de Kyber con la retención configurada por fuente y destino comparada contra 90 días / 12 meses.", "evidencia_en": "Kyber report of configured retention per source and destination compared against 90 days / 12 months.", "limitaciones": "Kyber mide la configuración, no confirma que no haya huecos históricos ni la disponibilidad real de bitácoras en SIEM externos.", "limitaciones_en": "Kyber measures configuration; it does not confirm the absence of historical gaps or actual availability in external SIEMs.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.15", "5.33" ], "soc2_tsc": [ "CC7.2" ], "cis_controls_v8": [ "8.10", "8.3" ], "banxico_spei": [ "58a. I.A.c).5", "58a. I.A.c).6", "58a. I.A.e).5", "58a. I.B.d)" ] } }, { "id": 166, "numero_regla": "10.6.1", "requisito": "10", "seccion": "10.6", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Sincronización de hora consistente en todos los sistemas", "seccion_titulo_en": "Time synchronization supports consistent time settings", "descripcion_corta": "Relojes de sistemas sincronizados mediante tecnología de sincronización de tiempo", "descripcion_larga": "Los relojes de los sistemas y la hora deben sincronizarse usando tecnología de sincronización de tiempo, para poder correlacionar eventos entre sistemas. Mantener esa tecnología vigente incluye gestionar sus vulnerabilidades y parches conforme a los Requisitos 6.3.1 y 6.3.3.", "remediacion": "1) AWS: configure chrony en las instancias EC2 para usar Amazon Time Sync Service (169.254.169.123 o fd00:ec2::123); las AMI de Amazon Linux lo traen por defecto. 2) Azure: use el host de Hyper-V (VMICTimeSync/PTP) o chrony con time.windows.com; en dominios, sincronice con el controlador de dominio. 3) GCP: use el servidor de metadatos metadata.google.internal (169.254.169.254) como fuente NTP. 4) Los servicios administrados (RDS, Lambda, etc.) los sincroniza el proveedor. 5) Mantenga chrony/ntpd parchado. El QSA pedirá la configuración de NTP de muestras de servidores.", "descripcion_corta_en": "System clocks synchronized using time-synchronization technology", "descripcion_larga_en": "System clocks and time must be synchronized using time-synchronization technology so events can be correlated across systems. Keeping that technology current includes managing its vulnerabilities and patches under Requirements 6.3.1 and 6.3.3.", "remediacion_en": "1) AWS: configure chrony on EC2 instances to use Amazon Time Sync Service (169.254.169.123 or fd00:ec2::123); Amazon Linux AMIs ship this by default. 2) Azure: use the Hyper-V host (VMICTimeSync/PTP) or chrony with time.windows.com; in domains, sync with the domain controller. 3) GCP: use the metadata server metadata.google.internal (169.254.169.254) as the NTP source. 4) Managed services (RDS, Lambda, etc.) are synchronized by the provider. 5) Keep chrony/ntpd patched. The QSA will ask for NTP configuration from sample servers.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 257, "pagina_pdf_es": 267 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Snapshots EC2: /etc/chrony.conf (o chrony.d) con server 169.254.169.123 o fd00:ec2::123 (falla si no hay fuente)", "Snapshots EC2: servicio chronyd o ntpd habilitado en el arranque", "Paquete chrony/ntp sin vulnerabilidades críticas conocidas (inventario de paquetes del snapshot)" ], "checks_azure": [ "Snapshots de VMs Linux: chrony configurado con refclock PHC (PTP de Hyper-V) o servidor NTP designado", "Snapshots de VMs Windows: W32Time configurado con NtpServer designado o VMICTimeProvider habilitado" ], "checks_gcp": [ "Snapshots de VMs: chrony/ntp con server metadata.google.internal o 169.254.169.254", "Snapshots de VMs: servicio de sincronización habilitado" ], "evidencia": "Configuración de NTP extraída de snapshots por VM y reporte de cumplimiento.", "evidencia_en": "NTP configuration extracted from snapshots per VM and compliance report.", "limitaciones": "No verifica la deriva real del reloj en ejecución ni dispositivos fuera de la nube; los servicios administrados se heredan del proveedor.", "limitaciones_en": "Does not verify actual runtime clock drift or devices outside the cloud; managed services are inherited from the provider.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.17" ], "soc2_tsc": [ "CC7.2" ], "cis_controls_v8": [ "8.4" ], "banxico_spei": [ "49a.", "58a. I.A.f).5" ] } }, { "id": 167, "numero_regla": "10.6.2", "requisito": "10", "seccion": "10.6", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Sincronización de hora consistente en todos los sistemas", "seccion_titulo_en": "Time synchronization supports consistent time settings", "descripcion_corta": "Configuración de hora correcta y consistente con servidores de tiempo designados", "descripcion_larga": "Los sistemas deben configurarse con hora correcta y consistente: usar uno o más servidores de tiempo designados; solo estos reciben la hora de fuentes externas; la hora externa se basa en el Tiempo Atómico Internacional o UTC; los servidores designados solo aceptan actualizaciones de fuentes externas específicas reconocidas por la industria; si hay varios, se sincronizan entre sí; y los sistemas internos reciben la hora solo de los servidores centrales designados.", "remediacion": "1) Designe como fuente central el servicio de tiempo del proveedor (Amazon Time Sync Service, host de Azure, servidor de metadatos de GCP), que se basa en UTC con relojes atómicos/GPS. 2) Configure todas las VMs para usar solo esa fuente; elimine pools públicos (pool.ntp.org) de chrony.conf. 3) Si opera servidores NTP propios, que solo ellos consulten fuentes externas reconocidas (p. ej. time.nist.gov), que se relacionen entre sí como peers y que bloqueen el resto por NSC. 4) Restrinja con security groups/NSG/firewall el UDP 123 saliente hacia Internet. 5) Configure zona horaria UTC. El QSA pedirá la arquitectura de tiempo y configuraciones de muestra.", "descripcion_corta_en": "Correct and consistent time configured using designated time servers", "descripcion_larga_en": "Systems must be configured with correct and consistent time: one or more designated time servers are used; only they receive time from external sources; external time is based on International Atomic Time or UTC; designated servers accept updates only from specific industry-recognized external sources; where there are several, they peer with each other; and internal systems receive time only from the designated central servers.", "remediacion_en": "1) Designate the provider's time service as the central source (Amazon Time Sync Service, Azure host, GCP metadata server), which is UTC-based with atomic/GPS clocks. 2) Configure all VMs to use only that source; remove public pools (pool.ntp.org) from chrony.conf. 3) If you run your own NTP servers, only they should query recognized external sources (e.g., time.nist.gov), they should peer with each other, and everything else should be blocked by NSCs. 4) Restrict outbound UDP 123 to the Internet via security groups/NSG/firewall. 5) Set the time zone to UTC. The QSA will ask for the time architecture and sample configurations.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 258, "pagina_pdf_es": 268 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Snapshots EC2: chrony.conf sin servidores/pools públicos distintos de la fuente designada (falla si hay pool.ntp.org u otros)", "Security groups/NACL del CDE: salida UDP 123 a 0.0.0.0/0 solo desde servidores NTP designados" ], "checks_azure": [ "Snapshots de VMs: configuración NTP apunta solo a la fuente designada", "NSG/Azure Firewall: salida UDP 123 a Internet restringida a servidores designados" ], "checks_gcp": [ "Snapshots de VMs: chrony/ntp apunta solo a metadata.google.internal o servidores designados", "Reglas de firewall VPC: egress UDP 123 a 0.0.0.0/0 restringido" ], "evidencia": "Configuración de fuentes NTP por VM y reglas de red asociadas al puerto 123.", "evidencia_en": "Per-VM NTP source configuration and network rules for port 123.", "limitaciones": "No puede confirmar la jerarquía ni el peering de servidores NTP fuera de la nube, ni la fuente de servicios administrados.", "limitaciones_en": "Cannot confirm hierarchy or peering of NTP servers outside the cloud, nor the source used by managed services.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.17" ], "soc2_tsc": [ "CC7.2" ], "cis_controls_v8": [ "8.4" ], "banxico_spei": [ "49a.", "58a. I.A.f).5" ] } }, { "id": 168, "numero_regla": "10.6.3", "requisito": "10", "seccion": "10.6", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Sincronización de hora consistente en todos los sistemas", "seccion_titulo_en": "Time synchronization supports consistent time settings", "descripcion_corta": "Protección de la configuración y los datos de sincronización de tiempo", "descripcion_larga": "La configuración y los datos de sincronización de tiempo deben protegerse: el acceso a los datos de hora debe limitarse al personal con necesidad de negocio y todo cambio en la configuración de hora de los sistemas críticos debe registrarse, monitorearse y revisarse.", "remediacion": "1) Restrinja quién puede modificar chrony.conf, la zona horaria y el servicio de tiempo (permisos de archivo root:root 644, sudo limitado, capacidad CAP_SYS_TIME solo al demonio). 2) Configure auditd con reglas para adjtimex, settimeofday, clock_settime y cambios a /etc/localtime y chrony.conf; en Windows audite el cambio de hora del sistema (Event ID 4616). 3) Envíe esos eventos al SIEM y cree una alerta. 4) Limite con IAM los cambios a imágenes o plantillas de lanzamiento que definan la configuración de tiempo. El QSA pedirá permisos de archivos, reglas de auditoría y ejemplos de eventos revisados.", "descripcion_corta_en": "Time synchronization settings and data are protected", "descripcion_larga_en": "Time synchronization settings and data must be protected: access to time data must be limited to personnel with a business need, and any change to time settings on critical systems must be logged, monitored and reviewed.", "remediacion_en": "1) Restrict who can modify chrony.conf, the time zone and the time service (file permissions root:root 644, limited sudo, CAP_SYS_TIME only for the daemon). 2) Configure auditd rules for adjtimex, settimeofday, clock_settime and changes to /etc/localtime and chrony.conf; on Windows audit system time changes (Event ID 4616). 3) Send those events to the SIEM and create an alert. 4) Limit through IAM changes to images or launch templates that define time configuration. The QSA will ask for file permissions, audit rules and sample reviewed events.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 259, "pagina_pdf_es": 269 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Snapshots EC2: /etc/chrony.conf propiedad de root y no escribible por grupo/otros", "Snapshots EC2: reglas auditd para adjtimex, settimeofday, clock_settime y /etc/localtime (CIS Linux)" ], "checks_azure": [ "Snapshots de VMs Linux: permisos de chrony.conf y reglas auditd de cambio de hora", "Snapshots de VMs Windows: política de auditoría de cambio de hora del sistema habilitada" ], "checks_gcp": [ "Snapshots de VMs: permisos de chrony.conf y reglas auditd de cambio de hora presentes" ], "evidencia": "Permisos de archivos de configuración de tiempo y reglas de auditoría extraídos de snapshots.", "evidencia_en": "Time configuration file permissions and audit rules extracted from snapshots.", "limitaciones": "No confirma que los eventos de cambio de hora se revisen efectivamente.", "limitaciones_en": "Does not confirm that time change events are actually reviewed.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.17", "8.15" ], "soc2_tsc": [ "CC7.2", "CC6.1" ], "cis_controls_v8": [ "8.4", "8.5" ], "banxico_spei": [ "49a." ] } }, { "id": 169, "numero_regla": "10.7.1", "requisito": "10", "seccion": "10.7", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Fallas de sistemas de control de seguridad críticos detectadas y atendidas", "seccion_titulo_en": "Failures of critical security control systems are detected and responded to", "descripcion_corta": "Detección y atención oportuna de fallas en controles críticos (solo proveedores de servicios)", "descripcion_larga": "Requisito adicional solo para proveedores de servicios: las fallas de los sistemas de control de seguridad críticos deben detectarse, alertarse y atenderse con prontitud, incluyendo al menos: controles de seguridad de la red (NSC), IDS/IPS, FIM, soluciones antimalware, controles de acceso físico, controles de acceso lógico, mecanismos de registro de auditoría y controles de segmentación (si se usan). Este requisito fue reemplazado por el 10.7.2 a partir del 31 de marzo de 2025.", "remediacion": "1) Trate este requisito con los mismos controles del 10.7.2, que lo sustituye desde el 31-mar-2025. 2) AWS: cree alarmas y reglas de EventBridge para StopLogging/DeleteTrail, deshabilitación de GuardDuty, paro del Config recorder, cambios en WAF/security groups y pérdida de heartbeat de agentes EDR/FIM. 3) Azure: alertas de Activity Log y reglas de salud de Sentinel/Defender. 4) GCP: alertas basadas en logs para sinks, firewall y SCC. 5) Enrute alertas a guardia 24x7 y documente tiempos de atención. El QSA pedirá el procedimiento, la lista de alarmas y ejemplos de alertas.", "descripcion_corta_en": "Timely detection and handling of critical security control failures (service providers only)", "descripcion_larga_en": "Additional requirement for service providers only: failures of critical security control systems must be detected, alerted and addressed promptly, including at least: network security controls (NSCs), IDS/IPS, FIM, anti-malware solutions, physical access controls, logical access controls, audit logging mechanisms and segmentation controls (if used). This requirement was superseded by 10.7.2 as of 31 March 2025.", "remediacion_en": "1) Treat this requirement with the same controls as 10.7.2, which supersedes it from 31 March 2025. 2) AWS: create alarms and EventBridge rules for StopLogging/DeleteTrail, GuardDuty disablement, Config recorder stop, WAF/security group changes and loss of EDR/FIM agent heartbeat. 3) Azure: Activity Log alerts and Sentinel/Defender health rules. 4) GCP: log-based alerts for sinks, firewall and SCC. 5) Route alerts to a 24x7 on-call and document handling times. The QSA will ask for the procedure, the list of alarms and sample alerts.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 260, "pagina_pdf_es": 270 }, "kyber_cobertura": { "tipo": "deteccion_presencia", "automatizacion": "media", "checks_aws": [ "Alarma de CloudWatch por cambios de configuración de CloudTrail (StopLogging/DeleteTrail) [CloudWatch.5]", "Regla de EventBridge que alerta si GuardDuty se deshabilita (DeleteDetector/UpdateDetector) o se suspende", "Alarma por cambios en AWS Config (StopConfigurationRecorder/DeleteDeliveryChannel) [CloudWatch.9]", "Alarma por cambios en security groups y NACL (falla si no existe)", "Alarma por deshabilitación o eliminación programada de llaves KMS [CloudWatch.7]", "Security Hub habilitado con notificación de hallazgos de controles en estado FAILED" ], "checks_azure": [ "Alerta de Activity Log para eliminación de Diagnostic settings y de reglas NSG", "Defender for Cloud: alerta o Azure Policy si un plan de Defender pasa a Free", "Sentinel: regla de salud de conectores de datos (SentinelHealth) habilitada", "Azure Monitor: alerta de heartbeat de agentes (Azure Monitor Agent) ausente" ], "checks_gcp": [ "Alerta basada en logs para cambios o eliminación de sinks y auditConfigs", "Alerta basada en logs para cambios en reglas de firewall VPC", "Notificación si Security Command Center o un servicio de detección se desactiva", "Cloud Monitoring: alerta por ausencia de métricas del Ops Agent (absence condition)" ], "evidencia": "Inventario de alarmas de falla de controles críticos y sus destinos, más procedimiento y registros de atención.", "evidencia_en": "Inventory of critical control failure alarms and their destinations, plus procedure and handling records.", "limitaciones": "Kyber verifica que existan alarmas, no que se atiendan con prontitud; controles físicos y herramientas de terceros quedan fuera.", "limitaciones_en": "Kyber verifies that alarms exist, not that they are handled promptly; physical controls and third-party tools are out of scope.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.16", "5.25" ], "soc2_tsc": [ "CC7.2", "CC7.3" ], "cis_controls_v8": [ "8.11", "13.1" ], "banxico_spei": [ "58a. I.A.f).10" ] } }, { "id": 170, "numero_regla": "10.7.2", "requisito": "10", "seccion": "10.7", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Fallas de sistemas de control de seguridad críticos detectadas y atendidas", "seccion_titulo_en": "Failures of critical security control systems are detected and responded to", "descripcion_corta": "Detección, alerta y atención oportuna de fallas en sistemas de control de seguridad críticos", "descripcion_larga": "Las fallas de los sistemas de control de seguridad críticos deben detectarse, alertarse y atenderse con prontitud, incluyendo al menos: NSC, IDS/IPS, mecanismos de detección de cambios, soluciones antimalware, controles de acceso físico y lógico, mecanismos de registro de auditoría, controles de segmentación (si se usan), mecanismos de revisión de bitácoras y herramientas de pruebas de seguridad automatizadas (si se usan). Aplica a todas las entidades, sustituye al 10.7.1 desde el 31 de marzo de 2025 y agrega dos sistemas críticos adicionales.", "remediacion": "1) AWS: alarmas de CloudWatch/EventBridge cuando CloudTrail se detiene o se modifica, GuardDuty se deshabilita, el Config recorder se detiene, Security Hub se desactiva, se cambian WAF/security groups/NACL o se deshabilitan llaves KMS; monitoree el heartbeat de agentes EDR/FIM/antimalware. 2) Azure: alertas de Activity Log para eliminación de Diagnostic settings y reglas NSG, alertas si Defender for Cloud baja de plan, y libro de salud de Sentinel (SentinelHealth) para conectores caídos. 3) GCP: alertas basadas en logs para cambios en sinks/auditConfigs/firewall y alertas por ausencia de datos de agentes. 4) Incluya escáneres automatizados (Inspector, Defender, SCC) y el propio SIEM. 5) Enrute a guardia 24x7 con SLA. El QSA pedirá el procedimiento, la lista de alarmas y evidencia de alertas.", "descripcion_corta_en": "Detection, alerting and timely handling of critical security control system failures", "descripcion_larga_en": "Failures of critical security control systems must be detected, alerted and addressed promptly, including at least: NSCs, IDS/IPS, change-detection mechanisms, anti-malware solutions, physical and logical access controls, audit logging mechanisms, segmentation controls (if used), audit log review mechanisms and automated security testing tools (if used). It applies to all entities, supersedes 10.7.1 from 31 March 2025 and adds two additional critical systems.", "remediacion_en": "1) AWS: CloudWatch/EventBridge alarms when CloudTrail is stopped or modified, GuardDuty is disabled, the Config recorder is stopped, Security Hub is disabled, WAF/security groups/NACLs change or KMS keys are disabled; monitor heartbeat of EDR/FIM/anti-malware agents. 2) Azure: Activity Log alerts for deletion of Diagnostic settings and NSG rules, alerts if Defender for Cloud plans are downgraded, and the Sentinel health workbook (SentinelHealth) for failed connectors. 3) GCP: log-based alerts for changes to sinks/auditConfigs/firewall and absence alerts for agent data. 4) Include automated scanners (Inspector, Defender, SCC) and the SIEM itself. 5) Route to a 24x7 on-call with SLAs. The QSA will ask for the procedure, the alarm list and alert evidence.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 261, "pagina_pdf_es": 271 }, "kyber_cobertura": { "tipo": "deteccion_presencia", "automatizacion": "media", "checks_aws": [ "Alarma de CloudWatch por cambios de configuración de CloudTrail (StopLogging/DeleteTrail) [CloudWatch.5]", "Regla de EventBridge que alerta si GuardDuty se deshabilita (DeleteDetector/UpdateDetector) o se suspende", "Alarma por cambios en AWS Config (StopConfigurationRecorder/DeleteDeliveryChannel) [CloudWatch.9]", "Alarma por cambios en security groups y NACL (falla si no existe)", "Alarma por deshabilitación o eliminación programada de llaves KMS [CloudWatch.7]", "Security Hub habilitado con notificación de hallazgos de controles en estado FAILED" ], "checks_azure": [ "Alerta de Activity Log para eliminación de Diagnostic settings y de reglas NSG", "Defender for Cloud: alerta o Azure Policy si un plan de Defender pasa a Free", "Sentinel: regla de salud de conectores de datos (SentinelHealth) habilitada", "Azure Monitor: alerta de heartbeat de agentes (Azure Monitor Agent) ausente" ], "checks_gcp": [ "Alerta basada en logs para cambios o eliminación de sinks y auditConfigs", "Alerta basada en logs para cambios en reglas de firewall VPC", "Notificación si Security Command Center o un servicio de detección se desactiva", "Cloud Monitoring: alerta por ausencia de métricas del Ops Agent (absence condition)" ], "evidencia": "Inventario de alarmas por cada sistema de control crítico, mapeo de cobertura y procedimiento de atención.", "evidencia_en": "Inventory of alarms per critical control system, coverage mapping and handling procedure.", "limitaciones": "Kyber verifica la presencia de alarmas en la nube, no su atención oportuna; no cubre controles físicos ni herramientas fuera de la nube.", "limitaciones_en": "Kyber verifies the presence of cloud alarms, not their timely handling; it does not cover physical controls or tools outside the cloud.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.16", "5.25" ], "soc2_tsc": [ "CC7.2", "CC7.3" ], "cis_controls_v8": [ "8.11", "13.1" ], "banxico_spei": [ "58a. I.A.f).10" ] } }, { "id": 171, "numero_regla": "10.7.3", "requisito": "10", "seccion": "10.7", "categoria": "Requisito 10: Registrar y supervisar todos los accesos a los componentes del sistema y a los datos de tarjetahabiente", "categoria_en": "Requirement 10: Log and Monitor All Access to System Components and Cardholder Data", "seccion_titulo": "Fallas de sistemas de control de seguridad críticos detectadas y atendidas", "seccion_titulo_en": "Failures of critical security control systems are detected and responded to", "descripcion_corta": "Respuesta oportuna a fallas de sistemas de control de seguridad críticos", "descripcion_larga": "Ante la falla de cualquier sistema de control de seguridad crítico se debe responder con prontitud, incluyendo: restaurar las funciones de seguridad; identificar y documentar la duración (fecha y hora de inicio y fin); identificar y documentar las causas y la remediación requerida; identificar y atender problemas de seguridad surgidos durante la falla; determinar si se requieren acciones adicionales; implementar controles para evitar que se repita; y reanudar el monitoreo. Hasta el 31 de marzo de 2025 solo aplicaba a proveedores de servicios; desde esa fecha aplica a todas las entidades.", "remediacion": "1) Defina un procedimiento de respuesta a fallas de controles con plantilla de registro: control afectado, hora de inicio y fin, causa raíz, remediación, eventos ocurridos durante la falla y acciones preventivas. 2) Integre las alarmas del 10.7.2 con el sistema de tickets/incidentes (p. ej. EventBridge → SNS → ITSM, Sentinel → Logic Apps, SCC → Pub/Sub). 3) Tras restaurar el control (p. ej. reactivar CloudTrail o GuardDuty), revise la actividad del periodo sin cobertura en otras fuentes (Config, flow logs). 4) Aplique remediación automática cuando sea posible (Config remediation, Azure Policy DeployIfNotExists). 5) Revise los incidentes en un análisis post mortem. El QSA pedirá registros de fallas con causa, duración y remediación.", "descripcion_corta_en": "Timely response to critical security control system failures", "descripcion_larga_en": "Failures of any critical security control system must be responded to promptly, including: restoring security functions; identifying and documenting the duration (start and end date and time); identifying and documenting the causes and required remediation; identifying and addressing security issues that arose during the failure; determining whether further actions are needed; implementing controls to prevent recurrence; and resuming monitoring. Until 31 March 2025 it applied only to service providers; since then it applies to all entities.", "remediacion_en": "1) Define a control failure response procedure with a record template: affected control, start and end time, root cause, remediation, events during the failure and preventive actions. 2) Integrate 10.7.2 alarms with the ticketing/incident system (e.g., EventBridge → SNS → ITSM, Sentinel → Logic Apps, SCC → Pub/Sub). 3) After restoring the control (e.g., re-enabling CloudTrail or GuardDuty), review activity during the coverage gap using other sources (Config, flow logs). 4) Apply automatic remediation where possible (Config remediation, Azure Policy DeployIfNotExists). 5) Review incidents in a post-mortem. The QSA will ask for failure records with cause, duration and remediation.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 262, "pagina_pdf_es": 272 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Procedimiento de respuesta a fallas de controles (generador de políticas de Kyber) y registros de fallas con causa, duración y remediación cargados por el cliente.", "evidencia_en": "Control failure response procedure (Kyber policy generator) and failure records with cause, duration and remediation uploaded by the customer.", "limitaciones": "Kyber puede señalar periodos en que un control estuvo deshabilitado según el historial de configuración, pero no valida la calidad de la respuesta.", "limitaciones_en": "Kyber can flag periods when a control was disabled from configuration history, but does not validate the quality of the response.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.24", "5.26", "5.27" ], "soc2_tsc": [ "CC7.4", "CC7.5" ], "cis_controls_v8": [ "17.4", "17.8" ] } }, { "id": 172, "numero_regla": "11.1.1", "requisito": "11", "seccion": "11.1", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Procesos y mecanismos de pruebas de seguridad definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for security testing are defined and understood", "descripcion_corta": "Políticas y procedimientos operativos de pruebas de seguridad (Requisito 11) gestionados", "descripcion_larga": "Las políticas de seguridad y los procedimientos operativos que respaldan las actividades del Requisito 11 (pruebas periódicas de la seguridad de sistemas y redes) deben estar documentados, mantenerse actualizados, estar en uso y ser conocidos por todas las partes involucradas. El objetivo es que las actividades de escaneo de vulnerabilidades, pruebas de penetración, detección de intrusiones y detección de cambios se ejecuten de forma repetible, consistente y conforme a la intención de la dirección.", "remediacion": "1. Redacte (o genere con el generador de políticas de Kyber) una política de pruebas de seguridad que cubra escaneos internos/externos, pruebas de penetración, IDS/IPS, FIM y detección de cambios en páginas de pago, indicando los servicios de nube usados (Amazon Inspector, Defender for Cloud, Security Command Center, etc.). 2. Documente procedimientos operativos paso a paso (frecuencias, umbrales, flujo de remediación). 3. Asigne un dueño y una fecha de revisión al menos anual y tras cambios significativos; mantenga control de versiones. 4. Publique la política en un repositorio accesible y registre el acuse de lectura del personal afectado. 5. Evidencia para el QSA: política aprobada y vigente, historial de versiones, procedimientos y registros de difusión/capacitación.", "descripcion_corta_en": "Security testing policies and operational procedures (Requirement 11) are managed", "descripcion_larga_en": "Security policies and operational procedures supporting Requirement 11 activities (regular testing of system and network security) must be documented, kept current, actively used, and known to everyone affected. The goal is that vulnerability scanning, penetration testing, intrusion detection, and change detection are carried out in a repeatable, consistent way that reflects management's intent.", "remediacion_en": "1. Write (or generate with Kyber's policy generator) a security testing policy covering internal/external scans, penetration testing, IDS/IPS, FIM, and payment page change detection, naming the cloud services in use (Amazon Inspector, Defender for Cloud, Security Command Center, etc.). 2. Document step-by-step operating procedures (frequencies, thresholds, remediation workflow). 3. Assign an owner and a review date at least annually and after significant changes; keep version control. 4. Publish the policy in an accessible repository and record acknowledgment by affected personnel. 5. QSA evidence: approved current policy, version history, procedures, and distribution/training records.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 265, "pagina_pdf_es": 275 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Política y procedimientos del Requisito 11 aprobados, con historial de revisiones y evidencia de difusión al personal; Kyber puede generar la plantilla de política.", "evidencia_en": "Approved Requirement 11 policy and procedures with review history and evidence of distribution to personnel; Kyber can generate the policy template.", "limitaciones": "El escaneo de nube no puede verificar que la política se conozca o se siga; requiere entrevistas y evidencia documental.", "limitaciones_en": "Cloud scanning cannot verify that the policy is known or followed; interviews and documentary evidence are required.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.1", "5.37" ], "soc2_tsc": [ "CC5.3" ], "cis_controls_v8": [ "7.1" ] } }, { "id": 173, "numero_regla": "11.1.2", "requisito": "11", "seccion": "11.1", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Procesos y mecanismos de pruebas de seguridad definidos y comprendidos", "seccion_titulo_en": "Processes and mechanisms for security testing are defined and understood", "descripcion_corta": "Roles y responsabilidades para las actividades del Requisito 11 documentados y asignados", "descripcion_larga": "Los roles y responsabilidades para ejecutar las actividades del Requisito 11 deben estar documentados, asignados formalmente y ser comprendidos por el personal responsable. Pueden incluirse en las políticas y procedimientos o en documentos separados, por ejemplo una matriz RACI, y se recomienda que el personal confirme su aceptación de las responsabilidades asignadas.", "remediacion": "1. Elabore una matriz RACI para escaneos de vulnerabilidades, pruebas de penetración, IDS/IPS, FIM y monitoreo de páginas de pago, identificando quién opera Amazon Inspector/Defender for Cloud/Security Command Center y quién remedia hallazgos. 2. Asegure la independencia organizacional: quien escanea o prueba no debe ser quien administra los sistemas evaluados. 3. Incluya los roles en descripciones de puesto u onboarding y recabe el acuse firmado de cada responsable. 4. Revise la matriz al menos anualmente y ante cambios de personal. 5. Evidencia para el QSA: matriz RACI aprobada, acuses de aceptación y entrevistas que confirmen el entendimiento.", "descripcion_corta_en": "Roles and responsibilities for Requirement 11 activities are documented and assigned", "descripcion_larga_en": "Roles and responsibilities for carrying out Requirement 11 activities must be documented, formally assigned, and understood by the responsible personnel. They can live within policies and procedures or in separate documents such as a RACI matrix, and personnel are encouraged to acknowledge acceptance of their assigned responsibilities.", "remediacion_en": "1. Build a RACI matrix for vulnerability scanning, penetration testing, IDS/IPS, FIM, and payment page monitoring, identifying who operates Amazon Inspector/Defender for Cloud/Security Command Center and who remediates findings. 2. Ensure organizational independence: whoever scans or tests should not be the administrator of the systems assessed. 3. Include roles in job descriptions or onboarding and collect signed acknowledgment from each owner. 4. Review the matrix at least annually and upon staffing changes. 5. QSA evidence: approved RACI matrix, acceptance acknowledgments, and interviews confirming understanding.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2024-03-31", "severidad": "info", "referencia_documento": { "pagina_pdf_en": 266, "pagina_pdf_es": 276 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Matriz RACI del Requisito 11 aprobada y acuses de aceptación del personal responsable.", "evidencia_en": "Approved Requirement 11 RACI matrix and acceptance acknowledgments from responsible personnel.", "limitaciones": "No verificable mediante escaneo de nube; depende de documentación y entrevistas.", "limitaciones_en": "Not verifiable through cloud scanning; depends on documentation and interviews.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.2" ], "soc2_tsc": [ "CC1.3" ], "cis_controls_v8": [] } }, { "id": 174, "numero_regla": "11.3.1", "requisito": "11", "seccion": "11.3", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Vulnerabilidades internas y externas identificadas, priorizadas y atendidas", "seccion_titulo_en": "External and internal vulnerabilities are identified, prioritized, and addressed", "descripcion_corta": "Escaneos internos de vulnerabilidades trimestrales con remediación de críticas y altas", "descripcion_larga": "La entidad debe realizar escaneos internos de vulnerabilidades al menos una vez cada tres meses, resolver todas las vulnerabilidades clasificadas como de riesgo alto o crítico según su propia clasificación de riesgos (Requisito 6.3.1) y volver a escanear para confirmar su corrección. La herramienta de escaneo debe mantenerse actualizada con la información de vulnerabilidades más reciente, y los escaneos deben ejecutarse por personal calificado con independencia organizacional respecto de los sistemas evaluados. No se requiere un QSA ni un ASV: puede hacerlo personal interno calificado y razonablemente independiente o una firma especializada.", "remediacion": "1. Active escaneo continuo en todas las cuentas/suscripciones/proyectos y regiones del CDE: Amazon Inspector (EC2, ECR, Lambda), Microsoft Defender for Servers Plan 2 con Defender Vulnerability Management y Defender for Containers, o GCP Security Command Center con VM Manager y Artifact Analysis; complemente con el escaneo de snapshots de Kyber. 2. Defina SLA de remediación según el Requisito 6.3.1 (p. ej., críticas ≤ 15 días, altas ≤ 30 días) y canalice los hallazgos a un sistema de tickets. 3. Genere y conserve al menos un reporte por trimestre (cuatro en 12 meses) y reportes de reescaneo que demuestren que no quedan críticas/altas abiertas. 4. Verifique que las firmas/bases de datos de vulnerabilidades del escáner se actualicen automáticamente. 5. Documente quién ejecuta y revisa los escaneos, garantizando independencia de los administradores. 6. Evidencia para el QSA: reportes trimestrales de los últimos 12 meses, reescaneos limpios, configuración del escáner y registro de responsables.", "descripcion_corta_en": "Quarterly internal vulnerability scans with remediation of critical and high findings", "descripcion_larga_en": "The entity must run internal vulnerability scans at least once every three months, resolve every vulnerability ranked high-risk or critical under its own risk ranking (Requirement 6.3.1), and rescan to confirm the fixes. The scanning tool must be kept current with the latest vulnerability information, and scans must be performed by qualified personnel who are organizationally independent of the systems being scanned. A QSA or ASV is not required: qualified, reasonably independent internal staff or a specialized firm may perform them.", "remediacion_en": "1. Enable continuous scanning across every CDE account/subscription/project and region: Amazon Inspector (EC2, ECR, Lambda), Microsoft Defender for Servers Plan 2 with Defender Vulnerability Management and Defender for Containers, or GCP Security Command Center with VM Manager and Artifact Analysis; complement with Kyber's snapshot scanning. 2. Define remediation SLAs per Requirement 6.3.1 (e.g., critical <= 15 days, high <= 30 days) and route findings to a ticketing system. 3. Produce and retain at least one report per quarter (four in 12 months) plus rescan reports showing no open critical/high findings. 4. Verify that scanner vulnerability feeds/signatures update automatically. 5. Document who runs and reviews scans, ensuring independence from administrators. 6. QSA evidence: quarterly reports for the last 12 months, clean rescans, scanner configuration, and an owner log.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 270, "pagina_pdf_es": 280 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "alta", "checks_aws": [ "Amazon Inspector habilitado para escaneo de EC2 en todas las cuentas y regiones del CDE [Inspector.1]", "Amazon Inspector habilitado para escaneo de imágenes ECR [Inspector.2] y de funciones Lambda [Inspector.3]", "Hallazgos de Inspector con severidad CRITICAL/HIGH en estado ACTIVE con antigüedad mayor al SLA definido (falla si existen)", "Instancias EC2 del CDE sin cobertura de escaneo (estado de cobertura de Inspector distinto de ACTIVELY_SCANNING) (falla si existen)", "Escaneo de vulnerabilidades de Kyber sobre snapshots de EBS: paquetes con CVE crítico/alto sin parche (falla si existen)" ], "checks_azure": [ "Microsoft Defender for Servers Plan 2 habilitado en las suscripciones del CDE con Defender Vulnerability Management como solución de evaluación", "Recomendación 'Machines should have vulnerability findings resolved' sin máquinas en estado no saludable con severidad alta/crítica", "Defender for Containers habilitado con evaluación de vulnerabilidades de imágenes en Azure Container Registry", "Escaneo de vulnerabilidades de Kyber sobre snapshots de discos administrados: CVE crítico/alto sin parche (falla si existen)" ], "checks_gcp": [ "Security Command Center (Premium/Enterprise) activo a nivel de organización con hallazgos de vulnerabilidad de VM Manager", "API de Artifact Analysis (Container Scanning) habilitada para Artifact Registry del CDE", "Hallazgos de vulnerabilidad SCC con severidad CRITICAL/HIGH en estado ACTIVE fuera del SLA (falla si existen)", "Escaneo de vulnerabilidades de Kyber sobre snapshots de Persistent Disk: CVE crítico/alto sin parche (falla si existen)" ], "evidencia": "Kyber genera reportes trimestrales de vulnerabilidades por activo (con historial y reescaneos) a partir de Inspector/Defender/SCC y de sus propios escaneos de snapshots; el cliente aporta su clasificación de riesgos (6.3.1) y evidencia de independencia del responsable.", "evidencia_en": "Kyber generates quarterly per-asset vulnerability reports (with history and rescans) from Inspector/Defender/SCC and its own snapshot scans; the customer provides its risk ranking (6.3.1) and evidence of the tester's independence.", "limitaciones": "El escaneo de snapshots no cubre memoria en ejecución ni dispositivos fuera de la nube; la independencia y calificación del personal deben demostrarse documentalmente.", "limitaciones_en": "Snapshot scanning does not cover running memory or devices outside the cloud; personnel independence and qualification must be demonstrated through documentation.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.8" ], "soc2_tsc": [ "CC7.1" ], "cis_controls_v8": [ "7.5", "7.7" ], "banxico_spei": [ "58a. I.A.b).3" ] }, "mapeo_ucf": [ { "clave": "UCF-VUL-003", "relacion": "equivalent", "cobertura_pct": 100 } ] }, { "id": 175, "numero_regla": "11.3.1.1", "requisito": "11", "seccion": "11.3", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Vulnerabilidades internas y externas identificadas, priorizadas y atendidas", "seccion_titulo_en": "External and internal vulnerabilities are identified, prioritized, and addressed", "descripcion_corta": "Gestión basada en riesgo de vulnerabilidades no críticas ni altas detectadas en escaneos internos", "descripcion_larga": "Todas las demás vulnerabilidades aplicables, es decir, las que no se clasifican como de riesgo alto o crítico según el Requisito 6.3.1, deben atenderse con base en el riesgo definido en un análisis de riesgos específico (targeted risk analysis) elaborado conforme a todos los elementos del Requisito 12.3.1. Se deben realizar reescaneos cuando sea necesario. Aunque tengan menor criticidad, todas representan una vía potencial de ataque y deben abordarse periódicamente.", "remediacion": "1. Elabore un análisis de riesgos específico (12.3.1) que fije plazos de remediación para vulnerabilidades medias y bajas (p. ej., medias ≤ 90 días, bajas ≤ 180 días o en el siguiente ciclo de parches). 2. Configure en Amazon Inspector, Defender for Cloud o Security Command Center filtros y reportes de hallazgos MEDIUM/LOW con su antigüedad. 3. Automatice el parcheo con AWS Systems Manager Patch Manager, Azure Update Manager o GCP VM Manager OS patch management. 4. Documente excepciones con controles compensatorios y fecha de revisión. 5. Reescanee tras aplicar parches. 6. Evidencia para el QSA: el análisis de riesgos aprobado, reportes de antigüedad de hallazgos medios/bajos y registros de excepciones.", "descripcion_corta_en": "Risk-based management of non-critical, non-high vulnerabilities found in internal scans", "descripcion_larga_en": "All other applicable vulnerabilities, meaning those not ranked high-risk or critical under Requirement 6.3.1, must be addressed according to the risk defined in a targeted risk analysis performed per all elements of Requirement 12.3.1. Rescans must be run as needed. Even lower-severity vulnerabilities offer a potential attack path and must be dealt with periodically.", "remediacion_en": "1. Produce a targeted risk analysis (12.3.1) that sets remediation timelines for medium and low vulnerabilities (e.g., medium <= 90 days, low <= 180 days or the next patch cycle). 2. Configure filters and reports in Amazon Inspector, Defender for Cloud, or Security Command Center for MEDIUM/LOW findings with their age. 3. Automate patching with AWS Systems Manager Patch Manager, Azure Update Manager, or GCP VM Manager OS patch management. 4. Document exceptions with compensating controls and a review date. 5. Rescan after patching. 6. QSA evidence: the approved risk analysis, aging reports for medium/low findings, and exception records.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 272, "pagina_pdf_es": 282 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Hallazgos de Amazon Inspector MEDIUM/LOW en estado ACTIVE con antigüedad mayor al plazo del análisis de riesgos (falla si existen)", "Instancias del CDE con cumplimiento de parches NON_COMPLIANT en Systems Manager Patch Manager [SSM.2]" ], "checks_azure": [ "Hallazgos de Defender Vulnerability Management de severidad media/baja con antigüedad mayor al plazo definido (falla si existen)", "Azure Update Manager: máquinas del CDE con actualizaciones pendientes fuera de plazo (falla si existen)" ], "checks_gcp": [ "Hallazgos de vulnerabilidad SCC MEDIUM/LOW activos fuera del plazo definido (falla si existen)", "VM Manager: reportes de parches con instancias del CDE sin aplicar actualizaciones disponibles (falla si existen)" ], "evidencia": "Kyber genera reportes de antigüedad de vulnerabilidades medias/bajas contra los plazos definidos; el cliente carga su análisis de riesgos específico (12.3.1).", "evidencia_en": "Kyber generates aging reports for medium/low vulnerabilities against the defined timelines; the customer uploads its targeted risk analysis (12.3.1).", "limitaciones": "Kyber no puede validar que los plazos del análisis de riesgos estén justificados; solo mide el cumplimiento contra los plazos configurados.", "limitaciones_en": "Kyber cannot validate that the risk analysis timelines are justified; it only measures compliance against the configured timelines.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.8" ], "soc2_tsc": [ "CC7.1", "CC3.2" ], "cis_controls_v8": [ "7.7" ] } }, { "id": 176, "numero_regla": "11.3.1.2", "requisito": "11", "seccion": "11.3", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Vulnerabilidades internas y externas identificadas, priorizadas y atendidas", "seccion_titulo_en": "External and internal vulnerabilities are identified, prioritized, and addressed", "descripcion_corta": "Escaneos internos de vulnerabilidades autenticados con privilegios suficientes", "descripcion_larga": "Los escaneos internos de vulnerabilidades deben ejecutarse de forma autenticada. Los sistemas que no puedan aceptar credenciales deben quedar documentados; los que sí las acepten deben escanearse con privilegios suficientes para revisar a fondo los recursos del sistema; y si las cuentas usadas para el escaneo permiten inicio de sesión interactivo, deben gestionarse conforme al Requisito 8.2.2. Las herramientas pueden ser basadas en host o en red. El objetivo es detectar vulnerabilidades locales que no son visibles de forma remota.", "remediacion": "1. Use escaneo con visibilidad local: Amazon Inspector para EC2 (agente SSM o modo híbrido agentless), Defender for Servers con escaneo sin agente de máquinas y Defender Vulnerability Management, o VM Manager/OS Config en GCP; el escaneo de snapshots de Kyber también inspecciona paquetes del sistema de archivos. 2. Asegure que todas las instancias del CDE estén administradas por SSM/Azure Arc/OS Config agent con un rol de servicio de mínimo privilegio suficiente para leer inventario de paquetes. 3. Si usa cuentas de escaneo con acceso interactivo (p. ej., escáner de red con SSH/WinRM), trátelas como cuentas compartidas/de sistema bajo 8.2.2: aprobación, uso excepcional, atribución individual y almacenamiento en un gestor de secretos. 4. Mantenga una lista documentada de sistemas que no aceptan credenciales (appliances, servicios administrados) y su justificación. 5. Evidencia para el QSA: configuración del escáner, reportes que muestren escaneo autenticado, inventario de excepciones y gestión de cuentas de escaneo.", "descripcion_corta_en": "Authenticated internal vulnerability scans with sufficient privileges", "descripcion_larga_en": "Internal vulnerability scans must use authenticated scanning. Systems unable to accept credentials must be documented; systems that do accept them must be scanned with privileges sufficient for a thorough review of system resources; and if scanning accounts allow interactive login, they must be managed under Requirement 8.2.2. Tools may be host-based or network-based. The aim is to detect local vulnerabilities that are not visible remotely.", "remediacion_en": "1. Use scanning with local visibility: Amazon Inspector for EC2 (SSM agent or hybrid agentless mode), Defender for Servers agentless machine scanning with Defender Vulnerability Management, or GCP VM Manager/OS Config; Kyber's snapshot scanning also inspects file-system packages. 2. Ensure all CDE instances are managed by SSM/Azure Arc/OS Config agent with a least-privilege service role sufficient to read package inventory. 3. If scanning accounts have interactive access (e.g., a network scanner using SSH/WinRM), manage them as shared/system accounts under 8.2.2: approval, exceptional use, individual attribution, and storage in a secrets manager. 4. Keep a documented list of systems that cannot accept credentials (appliances, managed services) with justification. 5. QSA evidence: scanner configuration, reports showing authenticated scanning, exception inventory, and scanning-account management.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 273, "pagina_pdf_es": 283 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Instancias EC2 del CDE administradas por Systems Manager [SSM.1] para habilitar escaneo de Inspector con visibilidad local", "Configuración de Amazon Inspector con modo de escaneo EC2 híbrido (agent-based + agentless) en la organización", "Instancias con estado de cobertura de Inspector 'UNMANAGED_EC2_INSTANCE' o sin SSM (falla si existen)", "Secretos de cuentas de escaneo almacenados en AWS Secrets Manager con rotación habilitada [SecretsManager.1]" ], "checks_azure": [ "Defender for Cloud: escaneo sin agente de máquinas (agentless scanning) habilitado en Defender for Servers Plan 2", "Máquinas del CDE sin solución de evaluación de vulnerabilidades instalada (falla si existen)", "Credenciales de cuentas de escaneo almacenadas en Azure Key Vault con fecha de expiración" ], "checks_gcp": [ "Agente OS Config habilitado (metadata enable-osconfig=TRUE) en las VM del CDE para inventario y reportes de vulnerabilidades", "VM del CDE sin inventario de OS Config reportado (falla si existen)", "Credenciales de cuentas de escaneo en Secret Manager con rotación configurada" ], "evidencia": "Kyber reporta cobertura de escaneo autenticado/local por activo y la lista de activos sin cobertura; el cliente documenta los sistemas que no aceptan credenciales y la gestión de cuentas de escaneo.", "evidencia_en": "Kyber reports authenticated/local scan coverage per asset and the list of uncovered assets; the customer documents systems that cannot accept credentials and how scanning accounts are managed.", "limitaciones": "Kyber no puede verificar escaneos autenticados de escáneres de red de terceros ni la gestión de cuentas interactivas fuera de la nube.", "limitaciones_en": "Kyber cannot verify authenticated scans from third-party network scanners or management of interactive accounts outside the cloud.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.8", "5.18" ], "soc2_tsc": [ "CC7.1" ], "cis_controls_v8": [ "7.5" ] } }, { "id": 177, "numero_regla": "11.3.1.3", "requisito": "11", "seccion": "11.3", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Vulnerabilidades internas y externas identificadas, priorizadas y atendidas", "seccion_titulo_en": "External and internal vulnerabilities are identified, prioritized, and addressed", "descripcion_corta": "Escaneos internos de vulnerabilidades después de cualquier cambio significativo", "descripcion_larga": "Después de cualquier cambio significativo, se deben realizar escaneos internos de vulnerabilidades, resolver las vulnerabilidades de riesgo alto o crítico (según el Requisito 6.3.1) y reescanear cuando sea necesario. Los escaneos los debe realizar personal calificado con independencia organizacional, sin que se requiera un QSA o ASV. Para los escaneos posteriores a cambios significativos no es obligatorio el escaneo autenticado del Requisito 11.3.1.2.", "remediacion": "1. Integre el escaneo al proceso de cambios (6.5.2): un cambio significativo no se cierra sin un escaneo que muestre cero críticas/altas en los componentes afectados. 2. Aproveche el escaneo continuo basado en eventos: Amazon Inspector reescanea al detectar nuevas instancias, paquetes o imágenes; Defender for Cloud y SCC reevalúan automáticamente; ejecute un escaneo bajo demanda de Kyber tras despliegues mayores. 3. Agregue escaneo de imágenes en el pipeline CI/CD (ECR enhanced scanning, Defender for DevOps, Artifact Analysis on-push) con bloqueo por severidad. 4. Vincule el reporte del escaneo al ticket de cambio. 5. Evidencia para el QSA: tickets de cambio significativo con su reporte de escaneo y reescaneo asociado.", "descripcion_corta_en": "Internal vulnerability scans after any significant change", "descripcion_larga_en": "After any significant change, internal vulnerability scans must be performed, high-risk and critical vulnerabilities (per Requirement 6.3.1) must be resolved, and rescans run as needed. Scans must be performed by qualified, organizationally independent personnel, though a QSA or ASV is not required. Authenticated scanning under Requirement 11.3.1.2 is not mandatory for scans run after significant changes.", "remediacion_en": "1. Embed scanning in the change process (6.5.2): a significant change is not closed without a scan showing zero critical/high findings on affected components. 2. Leverage event-driven continuous scanning: Amazon Inspector rescans when new instances, packages, or images appear; Defender for Cloud and SCC reassess automatically; run an on-demand Kyber scan after major deployments. 3. Add image scanning to the CI/CD pipeline (ECR enhanced scanning, Defender for DevOps, Artifact Analysis on-push) with severity gating. 4. Link the scan report to the change ticket. 5. QSA evidence: significant-change tickets with their associated scan and rescan reports.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 274, "pagina_pdf_es": 285 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Amazon Inspector con escaneo continuo habilitado para EC2/ECR/Lambda (reescaneo automático ante nuevos recursos o paquetes)", "ECR: escaneo mejorado (enhanced) con frecuencia CONTINUOUS_SCAN o SCAN_ON_PUSH en repositorios del CDE [ECR.1]", "Hallazgos CRITICAL/HIGH en recursos creados o modificados en los últimos 30 días (falla si existen)" ], "checks_azure": [ "Defender for Containers con evaluación de vulnerabilidades en push a Azure Container Registry", "Recursos del CDE creados/modificados recientemente con hallazgos de vulnerabilidad alta/crítica (falla si existen)" ], "checks_gcp": [ "Artifact Analysis con escaneo automático on-push en Artifact Registry del CDE", "Hallazgos SCC CRITICAL/HIGH en recursos con cambios recientes según Cloud Asset Inventory (falla si existen)" ], "evidencia": "Kyber correlaciona cambios detectados (Config/Activity Log/Cloud Asset Inventory) con el estado de vulnerabilidades posterior; el cliente aporta tickets de cambio vinculados.", "evidencia_en": "Kyber correlates detected changes (Config/Activity Log/Cloud Asset Inventory) with the subsequent vulnerability status; the customer provides linked change tickets.", "limitaciones": "Kyber no puede determinar qué cambios son 'significativos' según la definición de la entidad.", "limitaciones_en": "Kyber cannot determine which changes are 'significant' under the entity's definition.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.8", "8.32" ], "soc2_tsc": [ "CC7.1", "CC8.1" ], "cis_controls_v8": [ "7.5" ] } }, { "id": 178, "numero_regla": "11.3.2", "requisito": "11", "seccion": "11.3", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Vulnerabilidades internas y externas identificadas, priorizadas y atendidas", "seccion_titulo_en": "External and internal vulnerabilities are identified, prioritized, and addressed", "descripcion_corta": "Escaneos externos de vulnerabilidades trimestrales por un ASV aprobado por PCI SSC", "descripcion_larga": "Los escaneos externos de vulnerabilidades deben realizarse al menos una vez cada tres meses por un proveedor de escaneo aprobado por PCI SSC (ASV). Las vulnerabilidades deben resolverse hasta cumplir los requisitos de escaneo aprobado de la Guía del Programa ASV, con reescaneos según sea necesario. En la evaluación inicial no se exigen cuatro escaneos aprobados en 12 meses si el último fue aprobado, existe una política de escaneo trimestral y se corrigieron las vulnerabilidades señaladas; después sí deben existir cuatro escaneos trimestrales aprobados. Este requisito no admite el enfoque personalizado.", "remediacion": "1. Contrate un ASV listado en el sitio de PCI SSC. 2. Defina el alcance con todas las IP públicas y nombres DNS del CDE: Elastic IPs, balanceadores, CloudFront, API Gateway, Azure Public IPs/Front Door/Application Gateway, GCP external IPs y load balancers (Kyber puede generar este listado). 3. Notifique al proveedor de nube si su política lo requiere y permita el tráfico del ASV sin bloquear vía WAF solo para su origen documentado. 4. Programe escaneos trimestrales, remedie hallazgos y reescanee hasta obtener estado 'pass'; documente disputas y falsos positivos ante el ASV. 5. Evidencia para el QSA: cuatro reportes ASV aprobados de los últimos 12 meses (con portada de cumplimiento) y reescaneos.", "descripcion_corta_en": "Quarterly external vulnerability scans by a PCI SSC Approved Scanning Vendor", "descripcion_larga_en": "External vulnerability scans must be performed at least once every three months by a PCI SSC Approved Scanning Vendor (ASV). Vulnerabilities must be resolved until the ASV Program Guide passing-scan requirements are met, with rescans as needed. For an initial assessment, four passing scans within 12 months are not required if the latest scan passed, a quarterly scanning policy exists, and noted vulnerabilities were fixed; thereafter four passing quarterly scans must exist. This requirement is not eligible for the customized approach.", "remediacion_en": "1. Engage an ASV listed on the PCI SSC website. 2. Define scope with all public IPs and DNS names of the CDE: Elastic IPs, load balancers, CloudFront, API Gateway, Azure Public IPs/Front Door/Application Gateway, GCP external IPs and load balancers (Kyber can generate this list). 3. Notify the cloud provider if its policy requires it and allow ASV traffic without blocking it via WAF, only from its documented source. 4. Schedule quarterly scans, remediate findings, and rescan until 'pass'; document disputes and false positives with the ASV. 5. QSA evidence: four passing ASV reports from the last 12 months (with attestation cover sheet) and rescans.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 275, "pagina_pdf_es": 286 }, "kyber_cobertura": { "tipo": "servicio", "automatizacion": "baja", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Reportes ASV trimestrales aprobados y reescaneos de los últimos 12 meses; Kyber genera el inventario de superficie externa (IP públicas, endpoints y dominios) para definir el alcance del ASV.", "evidencia_en": "Passing quarterly ASV reports and rescans for the last 12 months; Kyber generates the external attack surface inventory (public IPs, endpoints, and domains) to define ASV scope.", "limitaciones": "Kyber no es un ASV; el escaneo externo aprobado debe realizarlo un proveedor certificado por PCI SSC.", "limitaciones_en": "Kyber is not an ASV; the passing external scan must be performed by a PCI SSC-approved vendor.", "responsabilidad_compartida": "cliente", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.8" ], "soc2_tsc": [ "CC7.1" ], "cis_controls_v8": [ "7.6" ], "banxico_spei": [ "58a. I.B.b)" ] }, "mapeo_ucf": [ { "clave": "UCF-VUL-003", "relacion": "partial", "cobertura_pct": 50, "nota_es": "El escaneo externo lo tiene que hacer un ASV aprobado.", "nota_en": "External scanning must be performed by an approved ASV." } ] }, { "id": 179, "numero_regla": "11.3.2.1", "requisito": "11", "seccion": "11.3", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Vulnerabilidades internas y externas identificadas, priorizadas y atendidas", "seccion_titulo_en": "External and internal vulnerabilities are identified, prioritized, and addressed", "descripcion_corta": "Escaneos externos de vulnerabilidades después de cualquier cambio significativo", "descripcion_larga": "Después de cualquier cambio significativo se deben realizar escaneos externos de vulnerabilidades, resolver las vulnerabilidades con puntaje CVSS de 4.0 o mayor y reescanear según sea necesario. Los escaneos deben ser realizados por personal calificado con independencia organizacional; no es obligatorio que sea un QSA o un ASV.", "remediacion": "1. Incluya en el proceso de cambios un escaneo externo cuando el cambio afecte componentes expuestos a Internet (nuevos balanceadores, IP públicas, reglas de WAF/NSC, versiones de servidores web). 2. Use un escáner externo calificado (el ASV o una herramienta de escaneo externo operada por personal independiente) apuntando a los endpoints modificados. 3. Remedie todo hallazgo con CVSS ≥ 4.0 y reescanee hasta que no queden. 4. Kyber puede detectar nuevos recursos con exposición pública (Elastic IP, ALB, Azure Public IP, GCP forwarding rules externas) para disparar el escaneo. 5. Evidencia para el QSA: tickets de cambio con el reporte de escaneo externo y reescaneo asociados.", "descripcion_corta_en": "External vulnerability scans after any significant change", "descripcion_larga_en": "After any significant change, external vulnerability scans must be performed, vulnerabilities with a CVSS score of 4.0 or higher must be resolved, and rescans run as needed. Scans must be performed by qualified, organizationally independent personnel; a QSA or ASV is not required.", "remediacion_en": "1. Include an external scan in the change process whenever a change affects Internet-facing components (new load balancers, public IPs, WAF/NSC rules, web server versions). 2. Use a qualified external scanner (the ASV or an external scanning tool run by independent personnel) against the changed endpoints. 3. Remediate every finding with CVSS >= 4.0 and rescan until none remain. 4. Kyber can detect newly publicly exposed resources (Elastic IP, ALB, Azure Public IP, external GCP forwarding rules) to trigger the scan. 5. QSA evidence: change tickets with the associated external scan and rescan reports.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 277, "pagina_pdf_es": 288 }, "kyber_cobertura": { "tipo": "servicio", "automatizacion": "baja", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Reportes de escaneo externo y reescaneo ligados a cambios significativos; Kyber aporta el listado de recursos con nueva exposición pública como disparador.", "evidencia_en": "External scan and rescan reports tied to significant changes; Kyber provides the list of newly publicly exposed resources as the trigger.", "limitaciones": "Kyber no ejecuta escaneos externos desde Internet; requiere un escáner externo operado por personal calificado.", "limitaciones_en": "Kyber does not perform external scans from the Internet; an external scanner run by qualified personnel is required.", "responsabilidad_compartida": "cliente", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.8", "8.32" ], "soc2_tsc": [ "CC7.1", "CC8.1" ], "cis_controls_v8": [ "7.6" ] } }, { "id": 180, "numero_regla": "11.4.1", "requisito": "11", "seccion": "11.4", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Pruebas de penetración internas y externas periódicas", "seccion_titulo_en": "External and internal penetration testing is regularly performed", "descripcion_corta": "Metodología de pruebas de penetración definida, documentada e implementada", "descripcion_larga": "La entidad debe definir, documentar e implementar una metodología de pruebas de penetración que incluya: enfoques aceptados por la industria; cobertura de todo el perímetro del CDE y de los sistemas críticos; pruebas desde dentro y fuera de la red; validación de los controles de segmentación y de reducción de alcance; pruebas a nivel de aplicación que identifiquen al menos las vulnerabilidades del Requisito 6.2.4; pruebas a nivel de red que abarquen los componentes de red y sistemas operativos; consideración de amenazas y vulnerabilidades experimentadas en los últimos 12 meses; un enfoque documentado para evaluar y atender el riesgo de las vulnerabilidades explotables encontradas; y retención de resultados y de actividades de remediación por al menos 12 meses.", "remediacion": "1. Adopte una metodología reconocida (NIST SP 800-115, OSSTMM, OWASP WSTG, PTES) y adáptela a la nube: pruebas del plano de control (IAM, políticas de recursos, metadatos IMDS), del plano de datos y de servicios administrados. 2. Defina el alcance: perímetro del CDE (balanceadores, API Gateway, CloudFront/Front Door, endpoints públicos), sistemas críticos, y pruebas desde Internet y desde redes internas (otras VPC/VNet/proyectos). 3. Incluya pruebas de segmentación entre cuentas/suscripciones/proyectos y VPC fuera de alcance. 4. Respete las políticas de pentest del proveedor de nube (AWS, Azure y GCP no requieren aprobación previa para la mayoría de servicios, pero prohíben pruebas de DoS). 5. Defina cómo se califican y remedian los hallazgos (6.3.1) y retenga reportes y evidencia de remediación ≥ 12 meses. 6. Evidencia para el QSA: documento de metodología aprobado y su aplicación en el último pentest.", "descripcion_corta_en": "Penetration testing methodology is defined, documented, and implemented", "descripcion_larga_en": "The entity must define, document, and implement a penetration testing methodology that includes: industry-accepted approaches; coverage of the entire CDE perimeter and critical systems; testing from both inside and outside the network; validation of segmentation and scope-reduction controls; application-layer testing identifying at least the vulnerabilities in Requirement 6.2.4; network-layer testing covering network components and operating systems; consideration of threats and vulnerabilities experienced in the last 12 months; a documented approach for assessing and addressing the risk of exploitable vulnerabilities found; and retention of test results and remediation records for at least 12 months.", "remediacion_en": "1. Adopt a recognized methodology (NIST SP 800-115, OSSTMM, OWASP WSTG, PTES) and adapt it to cloud: control-plane testing (IAM, resource policies, IMDS metadata), data-plane testing, and managed services. 2. Define scope: CDE perimeter (load balancers, API Gateway, CloudFront/Front Door, public endpoints), critical systems, and tests from the Internet and from internal networks (other VPCs/VNets/projects). 3. Include segmentation tests between accounts/subscriptions/projects and out-of-scope VPCs. 4. Follow the cloud provider's pentest policies (AWS, Azure, and GCP do not require prior approval for most services but prohibit DoS testing). 5. Define how findings are rated and remediated (6.3.1) and retain reports and remediation evidence >= 12 months. 6. QSA evidence: approved methodology document and its application in the latest pentest.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 278, "pagina_pdf_es": 289 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Documento de metodología de pruebas de penetración aprobado y reportes/remediaciones retenidos al menos 12 meses; Kyber puede aportar el inventario de perímetro y de controles de segmentación como insumo de alcance.", "evidencia_en": "Approved penetration testing methodology document and reports/remediations retained at least 12 months; Kyber can provide the perimeter and segmentation-control inventory as scoping input.", "limitaciones": "La suficiencia de la metodología solo la puede evaluar un QSA o especialista; no es verificable por escaneo.", "limitaciones_en": "Methodology adequacy can only be assessed by a QSA or specialist; it is not verifiable by scanning.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.8", "5.35" ], "soc2_tsc": [ "CC4.1" ], "cis_controls_v8": [ "18.1" ], "banxico_spei": [ "58a. I.A.b).6" ] } }, { "id": 181, "numero_regla": "11.4.2", "requisito": "11", "seccion": "11.4", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Pruebas de penetración internas y externas periódicas", "seccion_titulo_en": "External and internal penetration testing is regularly performed", "descripcion_corta": "Prueba de penetración interna anual y tras cambios significativos", "descripcion_larga": "Se deben realizar pruebas de penetración internas conforme a la metodología definida por la entidad, al menos una vez cada 12 meses y después de cualquier actualización o cambio significativo de infraestructura o aplicaciones. Deben ejecutarlas recursos internos calificados o terceros externos calificados con independencia organizacional, sin que se requiera un QSA o ASV.", "remediacion": "1. Contrate o asigne un equipo de pentest calificado (certificaciones como OSCP, GPEN, CREST) independiente de quienes administran el CDE. 2. Realice la prueba desde dentro del entorno de nube: desde una instancia o rol en una VPC/VNet/proyecto interno hacia el CDE y dentro del CDE, incluyendo escalamiento de privilegios en IAM, movimiento lateral entre cuentas y acceso a servicios administrados (RDS, S3, Key Vault, Cloud SQL). 3. Programe la prueba anual y dispare pruebas adicionales tras cambios significativos (migraciones, nuevas VPC, nuevos servicios en el CDE). 4. Registre alcance, reglas de enfrentamiento y resultados. 5. Evidencia para el QSA: alcance y reporte del último pentest interno, credenciales del probador y declaración de independencia.", "descripcion_corta_en": "Annual internal penetration test and after significant changes", "descripcion_larga_en": "Internal penetration testing must be performed per the entity's defined methodology, at least once every 12 months and after any significant infrastructure or application upgrade or change. It must be done by qualified internal resources or qualified external third parties with organizational independence; a QSA or ASV is not required.", "remediacion_en": "1. Engage or assign a qualified pentest team (certifications such as OSCP, GPEN, CREST) independent of those who administer the CDE. 2. Test from inside the cloud environment: from an instance or role in an internal VPC/VNet/project toward and within the CDE, including IAM privilege escalation, cross-account lateral movement, and access to managed services (RDS, S3, Key Vault, Cloud SQL). 3. Schedule the annual test and trigger additional tests after significant changes (migrations, new VPCs, new services in the CDE). 4. Record scope, rules of engagement, and results. 5. QSA evidence: scope and report of the latest internal pentest, tester credentials, and independence statement.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 280, "pagina_pdf_es": 292 }, "kyber_cobertura": { "tipo": "servicio", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Reporte del pentest interno de los últimos 12 meses (y de los posteriores a cambios significativos), alcance y evidencia de independencia del probador.", "evidencia_en": "Internal pentest report from the last 12 months (and after significant changes), scope, and evidence of tester independence.", "limitaciones": "Requiere un servicio humano de pruebas de penetración; Kyber no realiza explotación.", "limitaciones_en": "Requires a human penetration testing service; Kyber does not perform exploitation.", "responsabilidad_compartida": "cliente", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.8", "5.35" ], "soc2_tsc": [ "CC4.1", "CC7.1" ], "cis_controls_v8": [ "18.5" ], "banxico_spei": [ "58a. I.A.b).6" ] } }, { "id": 182, "numero_regla": "11.4.3", "requisito": "11", "seccion": "11.4", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Pruebas de penetración internas y externas periódicas", "seccion_titulo_en": "External and internal penetration testing is regularly performed", "descripcion_corta": "Prueba de penetración externa anual y tras cambios significativos", "descripcion_larga": "Se deben realizar pruebas de penetración externas conforme a la metodología definida por la entidad, al menos una vez cada 12 meses y después de cualquier actualización o cambio significativo de infraestructura o aplicaciones. Deben ejecutarlas recursos internos o terceros calificados con independencia organizacional, sin que se requiera un QSA o ASV.", "remediacion": "1. Contrate un equipo de pentest calificado e independiente. 2. Defina el alcance externo con todos los puntos de entrada públicos del CDE: CloudFront/Front Door/Cloud CDN, balanceadores, API Gateway/API Management/Apigee, endpoints de almacenamiento público, consolas y VPN (Kyber puede generar el listado). 3. Incluya pruebas de aplicación (OWASP Top 10 / 6.2.4) y de red, y pruebas de configuración de servicios expuestos. 4. Ejecute la prueba anual y tras cambios significativos en el perímetro. 5. Evidencia para el QSA: alcance, reporte del último pentest externo y evidencia de calificación e independencia.", "descripcion_corta_en": "Annual external penetration test and after significant changes", "descripcion_larga_en": "External penetration testing must be performed per the entity's defined methodology, at least once every 12 months and after any significant infrastructure or application upgrade or change. It must be done by qualified internal resources or qualified third parties with organizational independence; a QSA or ASV is not required.", "remediacion_en": "1. Engage a qualified, independent pentest team. 2. Define external scope with every public entry point of the CDE: CloudFront/Front Door/Cloud CDN, load balancers, API Gateway/API Management/Apigee, public storage endpoints, consoles, and VPNs (Kyber can generate the list). 3. Include application (OWASP Top 10 / 6.2.4) and network testing, plus configuration testing of exposed services. 4. Run the test annually and after significant perimeter changes. 5. QSA evidence: scope, latest external pentest report, and evidence of qualification and independence.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 281, "pagina_pdf_es": 293 }, "kyber_cobertura": { "tipo": "servicio", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Reporte del pentest externo de los últimos 12 meses, alcance basado en el inventario de superficie externa y evidencia de independencia.", "evidencia_en": "External pentest report from the last 12 months, scope based on the external attack surface inventory, and evidence of independence.", "limitaciones": "Requiere un servicio humano de pruebas de penetración.", "limitaciones_en": "Requires a human penetration testing service.", "responsabilidad_compartida": "cliente", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.8", "5.35" ], "soc2_tsc": [ "CC4.1", "CC7.1" ], "cis_controls_v8": [ "18.2" ], "banxico_spei": [ "58a. I.A.b).6" ] } }, { "id": 183, "numero_regla": "11.4.4", "requisito": "11", "seccion": "11.4", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Pruebas de penetración internas y externas periódicas", "seccion_titulo_en": "External and internal penetration testing is regularly performed", "descripcion_corta": "Corrección de vulnerabilidades explotables halladas en pruebas de penetración y nueva prueba", "descripcion_larga": "Las vulnerabilidades explotables y debilidades de seguridad encontradas durante las pruebas de penetración deben corregirse de acuerdo con la evaluación de riesgo de la entidad definida en el Requisito 6.3.1, y la prueba de penetración debe repetirse para verificar las correcciones.", "remediacion": "1. Registre cada hallazgo del pentest como ticket con severidad según su clasificación 6.3.1 y plazo de remediación. 2. Remedie en la nube (p. ej., endurecer políticas IAM, cerrar security groups/NSG/firewall rules, parchear, aplicar WAF) y documente la corrección. 3. Solicite al probador un retest de los hallazgos y conserve el reporte de verificación. 4. Para riesgos aceptados documente justificación y controles compensatorios aprobados. 5. Evidencia para el QSA: reporte original, tickets de remediación y reporte de retest con hallazgos cerrados.", "descripcion_corta_en": "Exploitable vulnerabilities found in penetration testing are corrected and retested", "descripcion_larga_en": "Exploitable vulnerabilities and security weaknesses found during penetration testing must be corrected in line with the entity's risk assessment defined in Requirement 6.3.1, and penetration testing must be repeated to verify the corrections.", "remediacion_en": "1. Log each pentest finding as a ticket with severity per your 6.3.1 ranking and a remediation deadline. 2. Remediate in the cloud (e.g., tighten IAM policies, close security groups/NSGs/firewall rules, patch, apply WAF) and document the fix. 3. Ask the tester for a retest of findings and keep the verification report. 4. For accepted risks, document justification and approved compensating controls. 5. QSA evidence: original report, remediation tickets, and retest report with findings closed.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 282, "pagina_pdf_es": 294 }, "kyber_cobertura": { "tipo": "servicio", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Reporte de retest que confirme la corrección de hallazgos y tickets de remediación asociados.", "evidencia_en": "Retest report confirming findings were corrected and the associated remediation tickets.", "limitaciones": "Kyber puede volver a verificar configuraciones de nube relacionadas, pero el retest de explotabilidad requiere al probador.", "limitaciones_en": "Kyber can re-verify related cloud configurations, but exploitability retesting requires the tester.", "responsabilidad_compartida": "cliente", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.8" ], "soc2_tsc": [ "CC7.1", "CC7.4" ], "cis_controls_v8": [ "18.3" ] } }, { "id": 184, "numero_regla": "11.4.5", "requisito": "11", "seccion": "11.4", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Pruebas de penetración internas y externas periódicas", "seccion_titulo_en": "External and internal penetration testing is regularly performed", "descripcion_corta": "Pruebas de penetración de los controles de segmentación anuales y tras cambios", "descripcion_larga": "Si se usa segmentación para aislar el CDE de otras redes, los controles de segmentación deben probarse mediante pruebas de penetración al menos una vez cada 12 meses y después de cualquier cambio en los controles o métodos de segmentación. Las pruebas deben cubrir todos los controles y métodos en uso, seguir la metodología de la entidad, confirmar que la segmentación es operativa y eficaz y aísla el CDE de todos los sistemas fuera de alcance, y confirmar la eficacia del aislamiento entre sistemas con distintos niveles de seguridad (Requisito 2.2.3). Las debe realizar personal calificado con independencia organizacional.", "remediacion": "1. Identifique todos los métodos de segmentación en uso en la nube: cuentas/suscripciones/proyectos dedicados al CDE, VPC/VNet separadas, security groups/NSG/firewall rules, NACL, Transit Gateway/Virtual WAN route tables, peering, Private Link/Private Service Connect y SCP/Azure Policy/Organization Policy. 2. Haga que el probador intente alcanzar el CDE desde cada segmento fuera de alcance (incluido acceso a nivel IAM entre cuentas) y documente puertos/protocolos probados. 3. Ejecute la prueba anual y tras cualquier cambio en estos controles; Kyber puede detectar cambios en rutas, peerings y reglas para disparar la prueba. 4. Remedie y reteste cualquier ruta abierta. 5. Evidencia para el QSA: reporte de pruebas de segmentación con alcance, resultados y declaración de independencia.", "descripcion_corta_en": "Annual penetration testing of segmentation controls and after changes", "descripcion_larga_en": "If segmentation is used to isolate the CDE from other networks, segmentation controls must be penetration-tested at least once every 12 months and after any change to segmentation controls or methods. Testing must cover all controls and methods in use, follow the entity's methodology, confirm segmentation is operational and effective and isolates the CDE from all out-of-scope systems, and confirm the effectiveness of isolation between systems with differing security levels (Requirement 2.2.3). It must be done by qualified personnel with organizational independence.", "remediacion_en": "1. Identify every segmentation method used in the cloud: dedicated CDE accounts/subscriptions/projects, separate VPCs/VNets, security groups/NSGs/firewall rules, NACLs, Transit Gateway/Virtual WAN route tables, peering, Private Link/Private Service Connect, and SCPs/Azure Policy/Organization Policy. 2. Have the tester attempt to reach the CDE from every out-of-scope segment (including cross-account IAM access) and document ports/protocols tested. 3. Run the test annually and after any change to these controls; Kyber can detect changes to routes, peerings, and rules to trigger the test. 4. Remediate and retest any open path. 5. QSA evidence: segmentation test report with scope, results, and independence statement.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 283, "pagina_pdf_es": 295 }, "kyber_cobertura": { "tipo": "servicio", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Reporte de pruebas de segmentación de los últimos 12 meses y tras cambios; Kyber aporta el inventario de controles de segmentación (peerings, rutas, reglas, relaciones de confianza entre cuentas) y alertas de cambio.", "evidencia_en": "Segmentation test report from the last 12 months and after changes; Kyber provides the segmentation-control inventory (peerings, routes, rules, cross-account trusts) and change alerts.", "limitaciones": "El análisis de configuración no sustituye la prueba técnica de segmentación por un probador calificado.", "limitaciones_en": "Configuration analysis does not replace technical segmentation testing by a qualified tester.", "responsabilidad_compartida": "compartida", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.22", "8.8" ], "soc2_tsc": [ "CC6.6", "CC4.1" ], "cis_controls_v8": [ "18.4", "12.2" ], "banxico_spei": [ "58a. I.A.f).3" ] } }, { "id": 185, "numero_regla": "11.4.6", "requisito": "11", "seccion": "11.4", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Pruebas de penetración internas y externas periódicas", "seccion_titulo_en": "External and internal penetration testing is regularly performed", "descripcion_corta": "Pruebas de segmentación semestrales para proveedores de servicios", "descripcion_larga": "Requisito adicional solo para proveedores de servicios: si se usa segmentación para aislar el CDE, los controles de segmentación deben probarse mediante pruebas de penetración al menos una vez cada seis meses y después de cualquier cambio en ellos. Aplican los mismos elementos que en 11.4.5: cubrir todos los controles y métodos, seguir la metodología definida, confirmar que el CDE queda aislado de todo sistema fuera de alcance, verificar el aislamiento entre sistemas con distintos niveles de seguridad, y ser realizadas por personal calificado e independiente.", "remediacion": "1. Aplique el mismo programa de pruebas de segmentación de 11.4.5 con frecuencia semestral. 2. Incluya todas las fronteras entre cuentas/suscripciones/proyectos, VPC/VNet, Transit Gateway, peerings y endpoints privados, así como la separación entre entornos de clientes si aplica. 3. Use la detección de cambios de Kyber sobre rutas, peerings y reglas de red como disparador de pruebas extraordinarias. 4. Remedie y reteste. 5. Evidencia para el QSA: dos reportes de segmentación en los últimos 12 meses (uno por semestre) más los posteriores a cambios.", "descripcion_corta_en": "Semi-annual segmentation testing for service providers", "descripcion_larga_en": "Additional requirement for service providers only: if segmentation is used to isolate the CDE, segmentation controls must be penetration-tested at least once every six months and after any change to them. The same elements as 11.4.5 apply: cover all controls and methods, follow the defined methodology, confirm the CDE is isolated from all out-of-scope systems, verify isolation between systems with differing security levels, and be performed by qualified, independent personnel.", "remediacion_en": "1. Apply the same 11.4.5 segmentation testing program on a semi-annual cadence. 2. Include every boundary between accounts/subscriptions/projects, VPCs/VNets, Transit Gateway, peerings, and private endpoints, plus separation between customer environments where relevant. 3. Use Kyber's change detection on routes, peerings, and network rules to trigger extra tests. 4. Remediate and retest. 5. QSA evidence: two segmentation reports in the last 12 months (one per half-year) plus those after changes.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 284, "pagina_pdf_es": 296 }, "kyber_cobertura": { "tipo": "servicio", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Reportes semestrales de pruebas de segmentación y posteriores a cambios; inventario de controles de segmentación generado por Kyber.", "evidencia_en": "Semi-annual segmentation test reports and post-change tests; Kyber-generated segmentation-control inventory.", "limitaciones": "El análisis de configuración no sustituye la prueba técnica de segmentación.", "limitaciones_en": "Configuration analysis does not replace technical segmentation testing.", "responsabilidad_compartida": "compartida", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.22", "8.8" ], "soc2_tsc": [ "CC6.6", "CC4.1" ], "cis_controls_v8": [ "18.4", "12.2" ] } }, { "id": 186, "numero_regla": "11.4.7", "requisito": "11", "seccion": "11.4", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Pruebas de penetración internas y externas periódicas", "seccion_titulo_en": "External and internal penetration testing is regularly performed", "descripcion_corta": "Proveedores multi-tenant apoyan las pruebas de penetración externas de sus clientes", "descripcion_larga": "Requisito adicional solo para proveedores de servicios multi-tenant: deben apoyar a sus clientes en las pruebas de penetración externas conforme a los Requisitos 11.4.3 y 11.4.4. Pueden hacerlo entregando a cada cliente evidencia (que puede estar censurada, pero suficiente) de que esas pruebas se realizaron sobre la infraestructura contratada por el cliente, o dando acceso oportuno para que el cliente realice sus propias pruebas. No pueden prohibir las pruebas de penetración. Ver también el Apéndice A1.", "remediacion": "1. Publique una política de pruebas de penetración para clientes (similar a la de AWS/Azure/GCP) que indique servicios permitidos, actividades prohibidas (p. ej., DoS) y canal de notificación. 2. Alternativamente, comparta con cada cliente un resumen o reporte censurado del pentest externo de su infraestructura suscrita, con evidencia de remediación y retest. 3. Defina SLA para atender solicitudes de pentest de clientes. 4. Evidencia para el QSA: política publicada, solicitudes atendidas o reportes entregados a clientes.", "descripcion_corta_en": "Multi-tenant providers support customers' external penetration testing", "descripcion_larga_en": "Additional requirement for multi-tenant service providers only: they must support their customers' external penetration testing under Requirements 11.4.3 and 11.4.4. They can either give each customer evidence (redacted but sufficient) that such testing was done on the customer's subscribed infrastructure, or provide prompt access so customers can run their own tests. They cannot forbid penetration testing. See also Appendix A1.", "remediacion_en": "1. Publish a customer penetration testing policy (similar to AWS/Azure/GCP) stating permitted services, prohibited activities (e.g., DoS), and the notification channel. 2. Alternatively, share with each customer a summary or redacted report of the external pentest on its subscribed infrastructure, with remediation and retest evidence. 3. Define SLAs for handling customer pentest requests. 4. QSA evidence: published policy, handled requests, or reports delivered to customers.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 285, "pagina_pdf_es": 297 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Política de pentest para clientes, registros de solicitudes atendidas o reportes censurados entregados a clientes.", "evidencia_en": "Customer pentest policy, records of handled requests, or redacted reports delivered to customers.", "limitaciones": "No verificable por escaneo de nube.", "limitaciones_en": "Not verifiable by cloud scanning.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.20", "8.8" ], "soc2_tsc": [ "CC2.3", "CC9.2" ], "cis_controls_v8": [ "18.2" ] } }, { "id": 187, "numero_regla": "11.5.1", "requisito": "11", "seccion": "11.5", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Intrusiones de red y cambios inesperados de archivos detectados", "seccion_titulo_en": "Network intrusions and unexpected file changes are detected and responded to", "descripcion_corta": "Detección/prevención de intrusiones en el perímetro y puntos críticos del CDE", "descripcion_larga": "Se deben usar técnicas de detección y/o prevención de intrusiones para monitorear todo el tráfico en el perímetro del CDE y en los puntos críticos dentro del CDE, alertar al personal ante compromisos sospechados y mantener actualizados todos los motores, líneas base y firmas. Las alertas deben ser atendidas por personal o por medios automatizados que impidan el compromiso de los componentes.", "remediacion": "1. AWS: habilite Amazon GuardDuty en todas las cuentas y regiones (con delegado de administración en Organizations) incluyendo protección de runtime/EKS; despliegue AWS Network Firewall en las VPC del CDE (inspección north-south y east-west vía Transit Gateway) con grupos de reglas Suricata administrados por AWS (threat signatures) en modo alerta/descarte. 2. Azure: use Azure Firewall Premium con IDPS en modo 'Alert and deny' y Microsoft Defender for Cloud/Defender for Servers; envíe a Microsoft Sentinel. 3. GCP: despliegue Cloud IDS con packet mirroring sobre las subredes del CDE o Cloud NGFW Enterprise con prevención de intrusiones, y active Event Threat Detection de SCC. 4. Mantenga firmas actualizadas automáticamente (grupos administrados) y enrute alertas por EventBridge/SNS, Logic Apps o Pub/Sub a la guardia de seguridad. 5. Evidencia para el QSA: diagramas con ubicación de sensores, configuración de IDS/IPS, evidencia de actualización de firmas y alertas atendidas.", "descripcion_corta_en": "Intrusion detection/prevention at the CDE perimeter and critical points", "descripcion_larga_en": "Intrusion-detection and/or intrusion-prevention techniques must be used to monitor all traffic at the CDE perimeter and at critical points inside the CDE, alert personnel to suspected compromises, and keep all engines, baselines, and signatures up to date. Alerts must be handled by personnel or by automated means that prevent components from being compromised.", "remediacion_en": "1. AWS: enable Amazon GuardDuty in every account and region (with an Organizations delegated admin), including runtime/EKS protection; deploy AWS Network Firewall in CDE VPCs (north-south and east-west inspection via Transit Gateway) with AWS-managed Suricata threat-signature rule groups in alert/drop mode. 2. Azure: use Azure Firewall Premium with IDPS in 'Alert and deny' mode plus Microsoft Defender for Cloud/Defender for Servers; forward to Microsoft Sentinel. 3. GCP: deploy Cloud IDS with packet mirroring on CDE subnets or Cloud NGFW Enterprise with intrusion prevention, and enable SCC Event Threat Detection. 4. Keep signatures auto-updated (managed rule groups) and route alerts via EventBridge/SNS, Logic Apps, or Pub/Sub to the security on-call. 5. QSA evidence: diagrams showing sensor placement, IDS/IPS configuration, signature update evidence, and handled alerts.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 287, "pagina_pdf_es": 299 }, "kyber_cobertura": { "tipo": "deteccion_presencia", "automatizacion": "media", "checks_aws": [ "Amazon GuardDuty habilitado en todas las cuentas y regiones del CDE [GuardDuty.1]", "AWS Network Firewall desplegado en las VPC del CDE con al menos un grupo de reglas stateful (Suricata) asociado a la política (falla si no existe)", "Uso de grupos de reglas administrados de amenazas de AWS Network Firewall para mantener firmas actualizadas", "Regla de EventBridge que enruta hallazgos de GuardDuty a SNS/SIEM (falla si no existe)", "AWS Network Firewall con registro de alertas (ALERT) hacia CloudWatch Logs/S3 habilitado" ], "checks_azure": [ "Azure Firewall con SKU Premium e IDPS en modo 'Alert and deny' en las VNet del CDE (falla si está en Off)", "Microsoft Defender for Servers habilitado en las suscripciones del CDE", "Configuración de diagnóstico de Azure Firewall enviando registros IDPS a Log Analytics/Sentinel", "Reglas de alerta o automatizaciones de Sentinel/Defender que notifiquen al personal" ], "checks_gcp": [ "Endpoint de Cloud IDS con política de packet mirroring sobre las VPC/subredes del CDE (falla si no existe)", "Security Command Center Event Threat Detection habilitado a nivel de organización", "Política de firewall de Cloud NGFW Enterprise con perfil de prevención de amenazas (alternativa a Cloud IDS)", "Notificaciones de hallazgos de SCC hacia Pub/Sub configuradas" ], "evidencia": "Kyber verifica la presencia y activación de IDS/IPS y del enrutamiento de alertas por cuenta/región/VPC; el cliente aporta diagramas con ubicación de sensores y evidencia de alertas atendidas.", "evidencia_en": "Kyber verifies the presence and activation of IDS/IPS and alert routing per account/region/VPC; the customer provides diagrams showing sensor placement and evidence of handled alerts.", "limitaciones": "Kyber confirma que las herramientas existen y están activas, no su eficacia de detección ni que todo el tráfico pase por los sensores en rutas complejas.", "limitaciones_en": "Kyber confirms the tools exist and are active, not their detection effectiveness or that all traffic traverses the sensors in complex routing.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.16", "8.20" ], "soc2_tsc": [ "CC7.2" ], "cis_controls_v8": [ "13.3", "13.8" ] } }, { "id": 188, "numero_regla": "11.5.1.1", "requisito": "11", "seccion": "11.5", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Intrusiones de red y cambios inesperados de archivos detectados", "seccion_titulo_en": "Network intrusions and unexpected file changes are detected and responded to", "descripcion_corta": "Detección y respuesta a canales encubiertos de comunicación de malware (proveedores)", "descripcion_larga": "Requisito adicional solo para proveedores de servicios: las técnicas de detección y/o prevención de intrusiones deben detectar, alertar o impedir y atender los canales de comunicación encubiertos de malware, como el túnel DNS hacia servidores de comando y control. El plan de respuesta a incidentes debe definir la respuesta ante su detección y el personal debe conocer las técnicas de comunicación encubierta y cómo responder.", "remediacion": "1. AWS: habilite GuardDuty (incluye análisis de registros DNS y hallazgos como Backdoor:EC2/C&CActivity y Trojan:EC2/DNSDataExfiltration) y Route 53 Resolver DNS Firewall con listas de dominios administradas por AWS en modo BLOCK; restrinja el egreso con Network Firewall (filtrado por dominio/SNI). 2. Azure: Azure Firewall Premium con inteligencia de amenazas en modo 'Alert and deny', proxy DNS habilitado e IDPS; Defender for DNS/Defender for Servers. 3. GCP: Cloud DNS logging, Event Threat Detection (detecciones de malware/criptominería por DNS), Cloud IDS y reglas de egreso restrictivas con Cloud NGFW. 4. Incluya en el plan de respuesta un playbook para comunicaciones C2 (aislar instancia, snapshot forense, rotación de credenciales). 5. Capacite al personal periódicamente. 6. Evidencia para el QSA: configuración de controles, playbook y registros de capacitación.", "descripcion_corta_en": "Detection and response to covert malware communication channels (service providers)", "descripcion_larga_en": "Additional requirement for service providers only: intrusion-detection and/or prevention techniques must detect, alert on or prevent, and address covert malware communication channels, such as DNS tunneling to command-and-control servers. The incident response plan must define the response when such channels are detected, and personnel must understand covert communication techniques and how to respond.", "remediacion_en": "1. AWS: enable GuardDuty (covers DNS log analysis and findings such as Backdoor:EC2/C&CActivity and Trojan:EC2/DNSDataExfiltration) and Route 53 Resolver DNS Firewall with AWS-managed domain lists in BLOCK mode; restrict egress with Network Firewall (domain/SNI filtering). 2. Azure: Azure Firewall Premium with threat intelligence in 'Alert and deny' mode, DNS proxy enabled, and IDPS; Defender for DNS/Defender for Servers. 3. GCP: Cloud DNS logging, Event Threat Detection (DNS-based malware/cryptomining detections), Cloud IDS, and restrictive egress rules with Cloud NGFW. 4. Add a C2-communication playbook to the incident response plan (isolate instance, forensic snapshot, credential rotation). 5. Train personnel periodically. 6. QSA evidence: control configuration, playbook, and training records.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 288, "pagina_pdf_es": 300 }, "kyber_cobertura": { "tipo": "deteccion_presencia", "automatizacion": "media", "checks_aws": [ "Amazon GuardDuty habilitado en todas las cuentas y regiones [GuardDuty.1]", "Route 53 Resolver DNS Firewall asociado a las VPC del CDE con listas de dominios administradas por AWS en acción BLOCK (falla si no existe)", "Registro de consultas de Route 53 Resolver habilitado para las VPC del CDE", "Security groups del CDE con egreso 0.0.0.0/0 en todos los puertos sin inspección de Network Firewall (falla si existe)" ], "checks_azure": [ "Azure Firewall con threatIntelMode = Deny y proxy DNS habilitado en las VNet del CDE", "Azure Firewall Premium con IDPS habilitado (Alert and deny)", "Microsoft Defender for Servers habilitado (incluye detecciones de DNS)" ], "checks_gcp": [ "Política de registro de Cloud DNS (enableLogging) en las VPC del CDE", "Security Command Center Event Threat Detection habilitado", "Reglas de firewall de egreso de las VPC del CDE sin 0.0.0.0/0 en todos los puertos (falla si existe)" ], "evidencia": "Kyber verifica la presencia de controles de DNS/egreso e IDS; el cliente aporta el playbook de respuesta a canales encubiertos y evidencia de capacitación.", "evidencia_en": "Kyber verifies the presence of DNS/egress and IDS controls; the customer provides the covert-channel response playbook and training evidence.", "limitaciones": "No se puede comprobar la eficacia de detección frente a técnicas encubiertas ni el conocimiento del personal.", "limitaciones_en": "Detection effectiveness against covert techniques and personnel knowledge cannot be verified.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.16", "8.23" ], "soc2_tsc": [ "CC7.2", "CC7.3" ], "cis_controls_v8": [ "13.3", "9.2" ] } }, { "id": 189, "numero_regla": "11.5.2", "requisito": "11", "seccion": "11.5", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Intrusiones de red y cambios inesperados de archivos detectados", "seccion_titulo_en": "Network intrusions and unexpected file changes are detected and responded to", "descripcion_corta": "Mecanismo de detección de cambios (FIM) en archivos críticos con comparación semanal", "descripcion_larga": "Se debe desplegar un mecanismo de detección de cambios, como herramientas de monitoreo de integridad de archivos (FIM), que alerte al personal ante modificaciones no autorizadas (cambios, adiciones y eliminaciones) de archivos críticos y que realice comparaciones de los archivos críticos al menos una vez por semana. Los archivos críticos suelen ser los que no cambian con regularidad y cuya modificación puede indicar un compromiso, como ejecutables del sistema y de aplicaciones, archivos de configuración y parámetros, y bitácoras de auditoría centralizadas o archivadas.", "remediacion": "1. Defina la lista de archivos y rutas críticas por plataforma (binarios del SO, configuración de servicios, archivos de aplicaciones, bitácoras archivadas). 2. AWS: use una solución FIM (de terceros o Systems Manager Inventory con colección de archivos sobre rutas críticas + AWS Config para registrar cambios) en todas las instancias del CDE; para bitácoras use validación de integridad de CloudTrail y S3 Object Lock. 3. Azure: active Defender for Servers Plan 2 con File Integrity Monitoring (basado en Defender for Endpoint) y defina rutas/registro a monitorear. 4. GCP: use una solución FIM de terceros o un agente de seguridad; proteja bitácoras con buckets con retención bloqueada. 5. Configure alertas en tiempo cercano al real y comparaciones al menos semanales; integre alertas al plan de respuesta (12.10.5). 6. Evidencia para el QSA: configuración del FIM, lista de archivos monitoreados y alertas/reportes semanales.", "descripcion_corta_en": "Change-detection mechanism (FIM) on critical files with weekly comparison", "descripcion_larga_en": "A change-detection mechanism, such as file integrity monitoring (FIM) tools, must be deployed to alert personnel to unauthorized modification (changes, additions, and deletions) of critical files and to compare critical files at least weekly. Critical files are usually those that rarely change and whose modification may indicate compromise, such as system and application executables, configuration and parameter files, and centrally stored or archived audit logs.", "remediacion_en": "1. Define the list of critical files and paths per platform (OS binaries, service configuration, application files, archived logs). 2. AWS: use a FIM solution (third-party, or Systems Manager Inventory with file collection on critical paths + AWS Config to record changes) on all CDE instances; for logs use CloudTrail log file validation and S3 Object Lock. 3. Azure: enable Defender for Servers Plan 2 File Integrity Monitoring (Defender for Endpoint-based) and define paths/registry keys to monitor. 4. GCP: use a third-party FIM solution or security agent; protect logs with buckets using locked retention. 5. Configure near-real-time alerts and at least weekly comparisons; integrate alerts into the incident response plan (12.10.5). 6. QSA evidence: FIM configuration, monitored-file list, and weekly alerts/reports.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 290, "pagina_pdf_es": 302 }, "kyber_cobertura": { "tipo": "deteccion_presencia", "automatizacion": "media", "checks_aws": [ "Instancias EC2 del CDE administradas por Systems Manager [SSM.1] con asociación de Inventory que incluya colección de archivos en rutas críticas", "AWS Config recorder habilitado y registrando todos los tipos de recurso, incluido AWS::SSM::ManagedInstanceInventory [Config.1]", "CloudTrail con validación de integridad de archivos de log habilitada [CloudTrail.4]", "Presencia de agente FIM de terceros detectada en snapshots de las instancias del CDE (falla si no existe)" ], "checks_azure": [ "Defender for Servers Plan 2 habilitado con File Integrity Monitoring activo y rutas definidas en las suscripciones del CDE", "Máquinas del CDE incorporadas a Defender for Endpoint (requisito del FIM)", "Cuentas de almacenamiento de bitácoras con política de inmutabilidad (WORM) habilitada" ], "checks_gcp": [ "Presencia de agente FIM de terceros en snapshots de las VM del CDE (falla si no existe)", "Buckets de Cloud Storage con bitácoras de auditoría con política de retención bloqueada (retentionPolicy.isLocked = true)", "Agente OS Config habilitado para inventario de software en las VM del CDE" ], "evidencia": "Kyber detecta la presencia y activación de mecanismos FIM y de inmutabilidad de bitácoras; el cliente aporta la lista de archivos críticos y evidencia de alertas y comparaciones semanales.", "evidencia_en": "Kyber detects the presence and activation of FIM mechanisms and log immutability; the customer provides the critical-file list and evidence of alerts and weekly comparisons.", "limitaciones": "Kyber no verifica que las rutas monitoreadas sean suficientes ni que las alertas se atiendan; GCP carece de FIM nativo.", "limitaciones_en": "Kyber does not verify that monitored paths are sufficient or that alerts are acted on; GCP lacks native FIM.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.16", "8.9" ], "soc2_tsc": [ "CC7.1", "CC8.1" ], "cis_controls_v8": [], "banxico_spei": [ "58a. I.A.b).2 bis", "58a. I.A.d).4" ] } }, { "id": 190, "numero_regla": "11.6.1", "requisito": "11", "seccion": "11.6", "categoria": "Requisito 11: Probar regularmente la seguridad de los sistemas y las redes", "categoria_en": "Requirement 11: Test Security of Systems and Networks Regularly", "seccion_titulo": "Cambios no autorizados en páginas de pago detectados", "seccion_titulo_en": "Unauthorized changes on payment pages are detected and responded to", "descripcion_corta": "Detección de cambios y manipulación en cabeceras HTTP y scripts de páginas de pago", "descripcion_larga": "Se debe desplegar un mecanismo de detección de cambios y manipulación que alerte al personal ante modificaciones no autorizadas (incluidos indicadores de compromiso, cambios, adiciones y eliminaciones) en las cabeceras HTTP relevantes para la seguridad y en el contenido de los scripts de las páginas de pago tal como las recibe el navegador del consumidor. El mecanismo debe evaluar las cabeceras y páginas recibidas al menos semanalmente o con la frecuencia definida en un análisis de riesgos específico (12.3.1). Aplica también a sitios que incrustan un formulario de pago de un TPSP (p. ej., iframe), aunque los scripts dentro del iframe son responsabilidad del TPSP; no se espera instalar software en los navegadores de los consumidores.", "remediacion": "1. Implemente una Content Security Policy estricta en las páginas de pago con directivas report-to/report-uri y monitoree las violaciones. 2. Agregue cabeceras de seguridad desde el borde: CloudFront response headers policy, Azure Front Door rule sets o cabeceras personalizadas en el balanceador de GCP. 3. Use un servicio de monitoreo sintético o anti-skimming que descargue la página de pago y compare scripts y cabeceras contra una línea base (al menos semanal), o un script de detección de manipulación embebido. 4. Use Subresource Integrity (SRI) para scripts de terceros. 5. Enrute alertas al plan de respuesta (12.10.5). 6. Evidencia para el QSA: configuración del mecanismo, páginas monitoreadas, resultados/alertas y, si aplica, el análisis de riesgos de la frecuencia.", "descripcion_corta_en": "Change and tamper detection on payment page HTTP headers and scripts", "descripcion_larga_en": "A change- and tamper-detection mechanism must be deployed to alert personnel to unauthorized modification (including indicators of compromise, changes, additions, and deletions) of security-impacting HTTP headers and script contents of payment pages as received by the consumer's browser. It must evaluate received headers and pages at least weekly or at the frequency defined in a targeted risk analysis (12.3.1). It also applies to sites embedding a TPSP's payment form (e.g., iframe), although scripts inside the iframe are the TPSP's responsibility; installing software in consumers' browsers is not expected.", "remediacion_en": "1. Implement a strict Content Security Policy on payment pages with report-to/report-uri directives and monitor violations. 2. Add security headers at the edge: CloudFront response headers policy, Azure Front Door rule sets, or custom headers on the GCP load balancer. 3. Use a synthetic monitoring or anti-skimming service that fetches the payment page and compares scripts and headers against a baseline (at least weekly), or an embedded tamper-detection script. 4. Use Subresource Integrity (SRI) for third-party scripts. 5. Route alerts into the incident response plan (12.10.5). 6. QSA evidence: mechanism configuration, monitored pages, results/alerts, and, if applicable, the frequency risk analysis.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 292, "pagina_pdf_es": 304 }, "kyber_cobertura": { "tipo": "fuera_alcance_agentless", "automatizacion": "baja", "checks_aws": [ "CloudFront: distribuciones que sirven páginas de pago con response headers policy que incluya Content-Security-Policy (falla si no existe)", "CloudFront: response headers policy con Strict-Transport-Security habilitado" ], "checks_azure": [ "Azure Front Door/Application Gateway: rule set que agregue la cabecera Content-Security-Policy a las rutas de pago (falla si no existe)" ], "checks_gcp": [ "Cloud Load Balancing: backend service con customResponseHeaders que incluya Content-Security-Policy para las rutas de pago (falla si no existe)" ], "evidencia": "Kyber puede verificar la configuración de cabeceras de seguridad en CDN/balanceadores; el cliente aporta la configuración y resultados del mecanismo de detección de manipulación de páginas de pago.", "evidencia_en": "Kyber can verify security header configuration on CDNs/load balancers; the customer provides the configuration and results of the payment page tamper-detection mechanism.", "limitaciones": "La detección de cambios en scripts tal como los recibe el navegador ocurre fuera del alcance del escaneo agentless de nube; Kyber solo valida cabeceras configuradas en el borde.", "limitaciones_en": "Detecting script changes as received by the browser is outside the scope of agentless cloud scanning; Kyber only validates headers configured at the edge.", "responsabilidad_compartida": "cliente", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.16", "8.26" ], "soc2_tsc": [ "CC7.1", "CC8.1" ], "cis_controls_v8": [ "16.1" ] } }, { "id": 191, "numero_regla": "12.3.1", "requisito": "12", "seccion": "12.3", "categoria": "Requisito 12: Respaldar la seguridad de la información con políticas y programas organizacionales", "categoria_en": "Requirement 12: Support Information Security with Organizational Policies and Programs", "seccion_titulo": "Riesgos al CDE identificados, evaluados y gestionados formalmente", "seccion_titulo_en": "Risks to the CDE are formally identified, evaluated, and managed", "descripcion_corta": "Análisis de riesgos específicos documentados para requisitos con frecuencia flexible", "descripcion_larga": "Para cada requisito de PCI DSS que exija un análisis de riesgos específico, este debe documentarse e incluir: los activos protegidos; las amenazas contra las que protege el requisito; los factores que contribuyen a la probabilidad y/o impacto de que se materialice la amenaza; y el análisis resultante que justifique cómo la frecuencia o los procesos definidos por la entidad minimizan esa probabilidad o impacto. Cada análisis debe revisarse al menos cada 12 meses para confirmar si sigue siendo válido y actualizarse cuando la revisión lo determine necesario.", "remediacion": "1. Identifique los requisitos que permiten frecuencia definida por la entidad (p. ej., 5.2.3.1, 5.3.2.1, 7.2.5.1, 8.6.3, 9.5.1.2.1, 10.4.2.1, 11.3.1.1, 11.6.1, 12.10.4.1). 2. Use una plantilla estándar (o la del generador de Kyber) con activos, amenazas, factores de probabilidad/impacto y justificación de la frecuencia elegida. 3. Apóyese en datos de la nube (hallazgos de GuardDuty/Defender/SCC, inventario y exposición) para sustentar la probabilidad. 4. Obtenga aprobación de la dirección y programe revisión anual. 5. Evidencia para el QSA: cada análisis firmado, con fecha de revisión y evidencia de actualización cuando proceda.", "descripcion_corta_en": "Documented targeted risk analyses for requirements with flexible frequency", "descripcion_larga_en": "For each PCI DSS requirement calling for a targeted risk analysis, the analysis must be documented and include: the assets protected; the threats the requirement guards against; the factors contributing to the likelihood and/or impact of a threat occurring; and the resulting analysis justifying how the entity's chosen frequency or processes minimize that likelihood or impact. Each analysis must be reviewed at least every 12 months to confirm it remains valid, and updated when the review shows it is needed.", "remediacion_en": "1. Identify requirements allowing an entity-defined frequency (e.g., 5.2.3.1, 5.3.2.1, 7.2.5.1, 8.6.3, 9.5.1.2.1, 10.4.2.1, 11.3.1.1, 11.6.1, 12.10.4.1). 2. Use a standard template (or Kyber's generator) covering assets, threats, likelihood/impact factors, and justification of the chosen frequency. 3. Use cloud data (GuardDuty/Defender/SCC findings, inventory, exposure) to support likelihood. 4. Obtain management approval and schedule an annual review. 5. QSA evidence: each signed analysis with its review date and evidence of updates where applicable.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 300, "pagina_pdf_es": 313 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Análisis de riesgos específicos firmados por requisito, con revisión anual; Kyber puede generar la plantilla y aportar datos de exposición como insumo.", "evidencia_en": "Signed targeted risk analyses per requirement with annual review; Kyber can generate the template and provide exposure data as input.", "limitaciones": "No verificable mediante escaneo; la calidad del análisis la evalúa el QSA.", "limitaciones_en": "Not verifiable by scanning; the analysis quality is assessed by the QSA.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.1" ], "soc2_tsc": [ "CC3.2" ], "cis_controls_v8": [] } }, { "id": 192, "numero_regla": "12.3.3", "requisito": "12", "seccion": "12.3", "categoria": "Requisito 12: Respaldar la seguridad de la información con políticas y programas organizacionales", "categoria_en": "Requirement 12: Support Information Security with Organizational Policies and Programs", "seccion_titulo": "Riesgos al CDE identificados, evaluados y gestionados formalmente", "seccion_titulo_en": "Risks to the CDE are formally identified, evaluated, and managed", "descripcion_corta": "Inventario y revisión anual de suites de cifrado y protocolos criptográficos en uso", "descripcion_larga": "Las suites de cifrado y protocolos criptográficos en uso deben documentarse y revisarse al menos cada 12 meses, incluyendo como mínimo: un inventario actualizado de todas las suites y protocolos en uso con su propósito y dónde se usan; monitoreo activo de las tendencias de la industria sobre su viabilidad; y un plan documentado para responder a cambios previstos en las vulnerabilidades criptográficas. Aplica a toda la criptografía usada para cumplir PCI DSS, como la que hace ilegible el PAN en almacenamiento y transmisión, protege contraseñas o forma parte de la autenticación.", "remediacion": "1. Genere con Kyber el inventario de políticas TLS y criptografía: políticas SSL de ELB/ALB/NLB, versión mínima de TLS de CloudFront y API Gateway, rds.force_ssl, tipos de llaves KMS y algoritmos de certificados ACM; en Azure, minTlsVersion de App Service/Storage/SQL, políticas SSL de Application Gateway y tipos de llave de Key Vault; en GCP, SSL policies (perfil y minTlsVersion), sslMode de Cloud SQL y algoritmos de Cloud KMS. 2. Complemente con criptografía de aplicación (hash de contraseñas, tokenización). 3. Asigne un responsable que monitoree avisos (NIST, IETF, proveedores de nube) y planifique migraciones (p. ej., retiro de TLS 1.0/1.1, preparación poscuántica). 4. Revise y apruebe el inventario y el plan al menos anualmente. 5. Evidencia para el QSA: inventario con propósito y ubicación, minuta de revisión anual y plan de respuesta.", "descripcion_corta_en": "Inventory and annual review of cryptographic cipher suites and protocols in use", "descripcion_larga_en": "Cryptographic cipher suites and protocols in use must be documented and reviewed at least every 12 months, including at minimum: a current inventory of all suites and protocols in use with their purpose and where used; active monitoring of industry trends on their continued viability; and a documented plan to respond to anticipated changes in cryptographic vulnerabilities. It applies to all cryptography used to meet PCI DSS, such as rendering PAN unreadable in storage and transit, protecting passwords, and authentication.", "remediacion_en": "1. Use Kyber to generate the TLS and cryptography inventory: ELB/ALB/NLB SSL policies, CloudFront and API Gateway minimum TLS, rds.force_ssl, KMS key specs, and ACM certificate algorithms; in Azure, minTlsVersion for App Service/Storage/SQL, Application Gateway SSL policies, and Key Vault key types; in GCP, SSL policies (profile and minTlsVersion), Cloud SQL sslMode, and Cloud KMS algorithms. 2. Add application cryptography (password hashing, tokenization). 3. Assign an owner to track advisories (NIST, IETF, cloud providers) and plan migrations (e.g., retiring TLS 1.0/1.1, post-quantum readiness). 4. Review and approve the inventory and plan at least annually. 5. QSA evidence: inventory with purpose and location, annual review minutes, and response plan.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 303, "pagina_pdf_es": 317 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Listado de listeners de ELB/ALB/NLB con su política SSL; falla si usa políticas que permiten TLS 1.0/1.1", "CloudFront: minimumProtocolVersion del viewer certificate (falla si es inferior a TLSv1.2_2021)", "API Gateway: securityPolicy de dominios personalizados (falla si es TLS_1_0)", "Inventario de llaves KMS (KeySpec, KeyUsage) y certificados ACM (KeyAlgorithm)" ], "checks_azure": [ "App Service/Functions: minTlsVersion (falla si es inferior a 1.2)", "Azure Storage: minimumTlsVersion = TLS1_2", "Application Gateway: política SSL (falla si permite TLS 1.0/1.1)", "Inventario de llaves y certificados de Key Vault (tipo y tamaño de llave)" ], "checks_gcp": [ "SSL policies de balanceadores: profile y minTlsVersion (falla si es TLS_1_0 o TLS_1_1)", "Cloud SQL: settings.ipConfiguration.sslMode = ENCRYPTED_ONLY o TRUSTED_CLIENT_CERTIFICATE_REQUIRED", "Inventario de llaves Cloud KMS (algorithm, protectionLevel)" ], "evidencia": "Kyber genera el inventario de suites de cifrado y protocolos configurados en servicios de nube (dónde y para qué); el cliente agrega la criptografía de aplicación, la revisión anual y el plan de respuesta.", "evidencia_en": "Kyber generates the inventory of cipher suites and protocols configured in cloud services (where and for what); the customer adds application cryptography, the annual review, and the response plan.", "limitaciones": "Kyber no ve la criptografía implementada dentro del código de aplicación ni en sistemas fuera de la nube; el monitoreo de tendencias es documental.", "limitaciones_en": "Kyber cannot see cryptography implemented inside application code or in systems outside the cloud; trend monitoring is documentary.", "responsabilidad_compartida": "cliente", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.24" ], "soc2_tsc": [ "CC6.1", "CC6.7" ], "cis_controls_v8": [ "3.10", "3.11" ] } }, { "id": 193, "numero_regla": "12.3.4", "requisito": "12", "seccion": "12.3", "categoria": "Requisito 12: Respaldar la seguridad de la información con políticas y programas organizacionales", "categoria_en": "Requirement 12: Support Information Security with Organizational Policies and Programs", "seccion_titulo": "Riesgos al CDE identificados, evaluados y gestionados formalmente", "seccion_titulo_en": "Risks to the CDE are formally identified, evaluated, and managed", "descripcion_corta": "Revisión anual de tecnologías de hardware y software en uso (soporte y fin de vida)", "descripcion_larga": "Las tecnologías de hardware y software en uso deben revisarse al menos cada 12 meses, incluyendo como mínimo: análisis de que siguen recibiendo oportunamente correcciones de seguridad del fabricante; análisis de que siguen apoyando (y no impiden) el cumplimiento de PCI DSS; documentación de anuncios o tendencias de la industria, como planes de fin de vida (EOL) anunciados por el fabricante; y un plan aprobado por la alta dirección para remediar tecnologías obsoletas, incluidas aquellas con EOL anunciado.", "remediacion": "1. Use Kyber para detectar componentes sin soporte: runtimes de Lambda/Functions/Cloud Functions obsoletos, versiones de motor de RDS/Azure SQL/Azure Database/Cloud SQL en fin de soporte estándar, versiones de EKS/AKS/GKE sin soporte, imágenes de SO EOL detectadas en snapshots y versiones de ElastiCache/OpenSearch. 2. Suscríbase a calendarios de deprecación de cada proveedor (AWS Health, Azure Service Health/Advisor, GCP release notes). 3. Documente anualmente el análisis de soporte y compatibilidad con PCI DSS de cada tecnología. 4. Elabore un plan de migración con fechas, aprobado por la alta dirección, para tecnologías EOL. 5. Evidencia para el QSA: reporte de revisión anual, listado de componentes EOL y plan aprobado.", "descripcion_corta_en": "Annual review of hardware and software technologies in use (support and end of life)", "descripcion_larga_en": "Hardware and software technologies in use must be reviewed at least every 12 months, including at minimum: analysis that they still receive timely security fixes from vendors; analysis that they still support (and do not prevent) PCI DSS compliance; documentation of industry announcements or trends, such as vendor end-of-life (EOL) plans; and a senior-management-approved plan to remediate outdated technologies, including those with announced EOL.", "remediacion_en": "1. Use Kyber to detect unsupported components: deprecated Lambda/Functions/Cloud Functions runtimes, RDS/Azure SQL/Azure Database/Cloud SQL engine versions past standard support, unsupported EKS/AKS/GKE versions, EOL OS images detected in snapshots, and ElastiCache/OpenSearch versions. 2. Subscribe to each provider's deprecation calendars (AWS Health, Azure Service Health/Advisor, GCP release notes). 3. Document the annual support and PCI DSS compatibility analysis for each technology. 4. Build a dated migration plan approved by senior management for EOL technologies. 5. QSA evidence: annual review report, list of EOL components, and approved plan.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 304, "pagina_pdf_es": 319 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Funciones Lambda con runtimes obsoletos o no soportados [Lambda.2] (falla si existen)", "Clústeres EKS con versión de Kubernetes fuera de soporte estándar [EKS.2] (falla si existen)", "Instancias RDS/Aurora con versión de motor en fin de soporte estándar o en RDS Extended Support (falla si existen)", "Snapshots de EC2 con sistema operativo en fin de vida (p. ej., distribuciones sin soporte del fabricante) (falla si existen)" ], "checks_azure": [ "App Service/Functions con versión de runtime o stack fuera de soporte (falla si existen)", "Clústeres AKS con versión de Kubernetes no soportada (falla si existen)", "Azure Database for MySQL/PostgreSQL con versión de motor retirada o próxima a retiro (falla si existen)", "Discos de VM con sistema operativo EOL detectado en snapshot (falla si existen)" ], "checks_gcp": [ "Cloud Functions/Cloud Run functions con runtime deprecado (falla si existen)", "Clústeres GKE con versión fuera de soporte o sin canal de versiones (falla si existen)", "Cloud SQL con databaseVersion en fin de vida (falla si existen)", "Discos de VM con sistema operativo EOL detectado en snapshot (falla si existen)" ], "evidencia": "Kyber genera el listado de tecnologías sin soporte o con EOL anunciado por cuenta y servicio; el cliente aporta el análisis anual y el plan de remediación aprobado por la alta dirección.", "evidencia_en": "Kyber generates the list of unsupported or announced-EOL technologies per account and service; the customer provides the annual analysis and the senior-management-approved remediation plan.", "limitaciones": "Kyber no cubre hardware ni software fuera de la nube, ni evalúa la compatibilidad de la tecnología con el cumplimiento de PCI DSS.", "limitaciones_en": "Kyber does not cover hardware or software outside the cloud, nor does it assess technology compatibility with PCI DSS compliance.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.8", "5.9" ], "soc2_tsc": [ "CC7.1", "CC3.2" ], "cis_controls_v8": [ "2.2" ] } }, { "id": 194, "numero_regla": "12.5.1", "requisito": "12", "seccion": "12.5", "categoria": "Requisito 12: Respaldar la seguridad de la información con políticas y programas organizacionales", "categoria_en": "Requirement 12: Support Information Security with Organizational Policies and Programs", "seccion_titulo": "Alcance de PCI DSS documentado y validado", "seccion_titulo_en": "PCI DSS scope is documented and validated", "descripcion_corta": "Inventario actualizado de componentes del sistema en el alcance de PCI DSS", "descripcion_larga": "Se debe mantener actualizado un inventario de todos los componentes del sistema que están en el alcance de PCI DSS, incluida una descripción de su función o uso.", "remediacion": "1. Etiquete los recursos del CDE y conectados (p. ej., pci-scope=cde|connected) y aplique la etiqueta con AWS Tag Policies/SCP, Azure Policy o GCP Organization Policy/labels obligatorias. 2. Genere el inventario con Kyber a partir de AWS Config/Resource Explorer, Azure Resource Graph y Cloud Asset Inventory, incluyendo función/uso, cuenta, región y propietario. 3. Detecte recursos sin etiqueta de alcance en cuentas del CDE. 4. Actualice el inventario de forma continua y revíselo al menos en cada confirmación de alcance (12.5.2). 5. Evidencia para el QSA: inventario exportado con descripción de función y evidencia de actualización periódica.", "descripcion_corta_en": "Current inventory of system components in PCI DSS scope", "descripcion_larga_en": "An inventory of all system components in PCI DSS scope, including a description of each component's function or use, must be maintained and kept current.", "remediacion_en": "1. Tag CDE and connected resources (e.g., pci-scope=cde|connected) and enforce tagging with AWS Tag Policies/SCPs, Azure Policy, or GCP Organization Policy/required labels. 2. Generate the inventory with Kyber from AWS Config/Resource Explorer, Azure Resource Graph, and Cloud Asset Inventory, including function/use, account, region, and owner. 3. Detect resources without a scope tag in CDE accounts. 4. Update the inventory continuously and review it at least at every scope confirmation (12.5.2). 5. QSA evidence: exported inventory with function descriptions and evidence of periodic updates.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 308, "pagina_pdf_es": 323 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "AWS Config recorder habilitado en todas las regiones con todos los tipos de recurso [Config.1]", "Recursos en cuentas del CDE sin etiqueta de alcance PCI ni etiqueta de propietario/función (falla si existen)", "Exportación de inventario vía AWS Resource Explorer/Config agregador a nivel de organización" ], "checks_azure": [ "Inventario vía Azure Resource Graph de las suscripciones del CDE", "Azure Policy que exige etiquetas de alcance y función en grupos de recursos del CDE (falla si no está asignada)", "Recursos sin etiqueta de alcance PCI (falla si existen)" ], "checks_gcp": [ "Cloud Asset Inventory habilitado y exportado a nivel de organización", "Recursos en proyectos del CDE sin label de alcance PCI ni de función (falla si existen)" ], "evidencia": "Kyber genera el inventario de componentes en alcance (por cuenta/suscripción/proyecto) con función/uso derivada de etiquetas; el cliente valida y completa componentes fuera de la nube.", "evidencia_en": "Kyber generates the in-scope component inventory (per account/subscription/project) with function/use derived from tags; the customer validates it and adds non-cloud components.", "limitaciones": "Kyber no inventaría componentes on-premises, dispositivos de usuario ni software de terceros fuera de la nube; la precisión depende del etiquetado.", "limitaciones_en": "Kyber does not inventory on-premises components, user devices, or third-party software outside the cloud; accuracy depends on tagging.", "responsabilidad_compartida": "cliente", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.9" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "1.1", "2.1" ], "banxico_spei": [ "58a. I.A.g)", "58a. I.A.g).1" ] } }, { "id": 195, "numero_regla": "12.5.2", "requisito": "12", "seccion": "12.5", "categoria": "Requisito 12: Respaldar la seguridad de la información con políticas y programas organizacionales", "categoria_en": "Requirement 12: Support Information Security with Organizational Policies and Programs", "seccion_titulo": "Alcance de PCI DSS documentado y validado", "seccion_titulo_en": "PCI DSS scope is documented and validated", "descripcion_corta": "Documentación y confirmación del alcance de PCI DSS anual y ante cambios significativos", "descripcion_larga": "La entidad debe documentar y confirmar el alcance de PCI DSS al menos cada 12 meses y ante cambios significativos en el entorno en alcance. La validación debe, como mínimo: identificar los flujos de datos por etapa de pago (autorización, captura, liquidación, contracargos, reembolsos) y canal de aceptación; actualizar los diagramas de flujo de datos (1.2.4); identificar todas las ubicaciones donde se almacenan, procesan y transmiten datos de cuenta, incluidas ubicaciones fuera del CDE definido, aplicaciones, transmisiones entre sistemas y respaldos; identificar los componentes en el CDE, conectados a él o que pueden afectar su seguridad; identificar los controles de segmentación y los entornos segmentados con justificación de su exclusión; identificar las conexiones de terceros con acceso al CDE; y confirmar que todo lo anterior está incluido en el alcance.", "remediacion": "1. Use Kyber para descubrir la topología del alcance: VPC/VNet peerings, Transit Gateway/Virtual WAN, Private Link/Private Service Connect, relaciones de confianza IAM entre cuentas, reglas de red hacia el CDE y conexiones de terceros (roles con cuentas externas, VPN/Direct Connect/ExpressRoute/Interconnect). 2. Busque datos de cuenta fuera del CDE con Amazon Macie, Microsoft Purview o Sensitive Data Protection, incluidos respaldos y snapshots. 3. Actualice diagramas de red y de flujo de datos (1.2.3/1.2.4). 4. Documente la justificación de entornos fuera de alcance y los controles de segmentación. 5. Ejecute la confirmación al menos anualmente y tras cambios significativos, con aprobación formal. 6. Evidencia para el QSA: documento de confirmación de alcance fechado con todos los elementos y anexos (inventario, diagramas, resultados de descubrimiento de datos).", "descripcion_corta_en": "PCI DSS scope documented and confirmed annually and upon significant change", "descripcion_larga_en": "The entity must document and confirm PCI DSS scope at least every 12 months and upon significant change to the in-scope environment. Scoping validation must at minimum: identify data flows for each payment stage (authorization, capture, settlement, chargebacks, refunds) and acceptance channel; update data-flow diagrams (1.2.4); identify all locations where account data is stored, processed, and transmitted, including locations outside the defined CDE, applications, transmissions between systems, and backups; identify components in, connected to, or able to affect the security of the CDE; identify segmentation controls and segmented environments with justification for exclusion; identify third-party connections with CDE access; and confirm all of the above are in scope.", "remediacion_en": "1. Use Kyber to discover scope topology: VPC/VNet peerings, Transit Gateway/Virtual WAN, Private Link/Private Service Connect, cross-account IAM trust relationships, network rules into the CDE, and third-party connections (roles trusting external accounts, VPN/Direct Connect/ExpressRoute/Interconnect). 2. Search for account data outside the CDE with Amazon Macie, Microsoft Purview, or Sensitive Data Protection, including backups and snapshots. 3. Update network and data-flow diagrams (1.2.3/1.2.4). 4. Document justification for out-of-scope environments and segmentation controls. 5. Run the confirmation at least annually and after significant changes, with formal approval. 6. QSA evidence: dated scope confirmation document covering all elements with attachments (inventory, diagrams, data discovery results).", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 309, "pagina_pdf_es": 324 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Listado de VPC peerings, adjuntos de Transit Gateway y endpoints de PrivateLink conectados a cuentas del CDE", "Roles IAM con políticas de confianza hacia cuentas AWS externas a la organización (conexiones de terceros)", "Amazon Macie con hallazgos de datos de tarjeta en buckets S3 fuera de cuentas del CDE (falla si existen)", "Conexiones VPN/Direct Connect asociadas a VPC del CDE" ], "checks_azure": [ "Listado de VNet peerings, hubs de Virtual WAN y Private Endpoints conectados a suscripciones del CDE", "Delegaciones de Azure Lighthouse y usuarios invitados con roles en suscripciones del CDE", "Hallazgos de Microsoft Purview/Defender for Storage con datos de tarjeta fuera del CDE (falla si existen)" ], "checks_gcp": [ "Listado de VPC peerings, Shared VPC, Private Service Connect y Cloud Interconnect/VPN conectados a proyectos del CDE", "Bindings IAM a principales de dominios externos en proyectos del CDE", "Hallazgos de Sensitive Data Protection (discovery) con datos de tarjeta fuera del CDE (falla si existen)" ], "evidencia": "Kyber genera insumos de la confirmación de alcance (inventario, conexiones, segmentación, ubicaciones de datos de cuenta detectadas); el cliente documenta flujos por etapa de pago y canal, la justificación de exclusiones y la aprobación formal.", "evidencia_en": "Kyber generates scope confirmation inputs (inventory, connections, segmentation, detected account data locations); the customer documents flows per payment stage and channel, exclusion justifications, and formal approval.", "limitaciones": "Kyber no identifica flujos de negocio, canales de aceptación ni componentes fuera de la nube; la confirmación es responsabilidad de la entidad.", "limitaciones_en": "Kyber does not identify business flows, acceptance channels, or components outside the cloud; confirmation is the entity's responsibility.", "responsabilidad_compartida": "cliente", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.9", "5.12" ], "soc2_tsc": [ "CC3.2", "CC2.1" ], "cis_controls_v8": [ "1.1", "3.2", "3.8" ] } }, { "id": 196, "numero_regla": "12.5.2.1", "requisito": "12", "seccion": "12.5", "categoria": "Requisito 12: Respaldar la seguridad de la información con políticas y programas organizacionales", "categoria_en": "Requirement 12: Support Information Security with Organizational Policies and Programs", "seccion_titulo": "Alcance de PCI DSS documentado y validado", "seccion_titulo_en": "PCI DSS scope is documented and validated", "descripcion_corta": "Confirmación semestral del alcance de PCI DSS para proveedores de servicios", "descripcion_larga": "Requisito adicional solo para proveedores de servicios: el alcance de PCI DSS debe documentarse y confirmarse al menos cada seis meses y ante cambios significativos en el entorno en alcance, incluyendo como mínimo todos los elementos del Requisito 12.5.2.", "remediacion": "1. Aplique el proceso de 12.5.2 con frecuencia semestral y tras cambios significativos. 2. Programe ejecuciones de descubrimiento de Kyber (conexiones, peerings, relaciones de confianza, datos de cuenta fuera del CDE) cada seis meses y alertas continuas ante cambios en la topología. 3. Actualice inventario y diagramas en cada ciclo. 4. Obtenga aprobación formal de cada confirmación. 5. Evidencia para el QSA: dos confirmaciones de alcance en los últimos 12 meses con todos los elementos de 12.5.2.", "descripcion_corta_en": "Semi-annual PCI DSS scope confirmation for service providers", "descripcion_larga_en": "Additional requirement for service providers only: PCI DSS scope must be documented and confirmed at least every six months and upon significant change to the in-scope environment, covering at minimum all elements of Requirement 12.5.2.", "remediacion_en": "1. Apply the 12.5.2 process on a semi-annual cadence and after significant changes. 2. Schedule Kyber discovery runs (connections, peerings, trust relationships, account data outside the CDE) every six months plus continuous alerts on topology changes. 3. Update inventory and diagrams each cycle. 4. Obtain formal approval of each confirmation. 5. QSA evidence: two scope confirmations in the last 12 months covering all 12.5.2 elements.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 311, "pagina_pdf_es": 326 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Listado de VPC peerings, adjuntos de Transit Gateway y endpoints de PrivateLink conectados a cuentas del CDE", "Roles IAM con confianza hacia cuentas externas a la organización", "Amazon Macie con hallazgos de datos de tarjeta fuera de cuentas del CDE (falla si existen)" ], "checks_azure": [ "Listado de VNet peerings y Private Endpoints conectados a suscripciones del CDE", "Hallazgos de Microsoft Purview con datos de tarjeta fuera del CDE (falla si existen)" ], "checks_gcp": [ "Listado de VPC peerings, Shared VPC y Private Service Connect conectados a proyectos del CDE", "Hallazgos de Sensitive Data Protection con datos de tarjeta fuera del CDE (falla si existen)" ], "evidencia": "Insumos semestrales de alcance generados por Kyber y documentos de confirmación aprobados por el cliente.", "evidencia_en": "Semi-annual scope inputs generated by Kyber and customer-approved confirmation documents.", "limitaciones": "Igual que 12.5.2: la confirmación formal y los elementos de negocio son responsabilidad del proveedor de servicios.", "limitaciones_en": "Same as 12.5.2: formal confirmation and business elements are the service provider's responsibility.", "responsabilidad_compartida": "cliente", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.9", "5.12" ], "soc2_tsc": [ "CC3.2", "CC2.1" ], "cis_controls_v8": [ "1.1", "3.8" ] } }, { "id": 197, "numero_regla": "12.5.3", "requisito": "12", "seccion": "12.5", "categoria": "Requisito 12: Respaldar la seguridad de la información con políticas y programas organizacionales", "categoria_en": "Requirement 12: Support Information Security with Organizational Policies and Programs", "seccion_titulo": "Alcance de PCI DSS documentado y validado", "seccion_titulo_en": "PCI DSS scope is documented and validated", "descripcion_corta": "Revisión del impacto en el alcance ante cambios en la estructura organizacional (proveedores)", "descripcion_larga": "Requisito adicional solo para proveedores de servicios: los cambios significativos en la estructura organizacional deben generar una revisión interna documentada de su impacto en el alcance de PCI DSS y en la aplicabilidad de los controles, cuyos resultados se comuniquen a la dirección ejecutiva.", "remediacion": "1. Defina qué constituye un cambio organizacional significativo (fusiones, adquisiciones, reestructuras, cambios en responsables de seguridad, nuevas unidades de negocio). 2. Establezca un procedimiento que dispare la revisión de alcance y controles, incluyendo la reorganización de cuentas/suscripciones/proyectos y jerarquías (AWS Organizations OU, grupos de administración de Azure, carpetas de GCP). 3. Documente resultados y preséntelos a la dirección ejecutiva (minuta). 4. Evidencia para el QSA: procedimiento, revisiones documentadas y evidencia de comunicación a la dirección.", "descripcion_corta_en": "Scope impact review upon organizational structure changes (service providers)", "descripcion_larga_en": "Additional requirement for service providers only: significant changes to organizational structure must trigger a documented internal review of their impact on PCI DSS scope and control applicability, with results communicated to executive management.", "remediacion_en": "1. Define what counts as a significant organizational change (mergers, acquisitions, restructurings, changes in security leadership, new business units). 2. Establish a procedure that triggers review of scope and controls, including reorganization of accounts/subscriptions/projects and hierarchies (AWS Organizations OUs, Azure management groups, GCP folders). 3. Document results and present them to executive management (minutes). 4. QSA evidence: procedure, documented reviews, and evidence of communication to management.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 312, "pagina_pdf_es": 327 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Procedimiento de revisión y minutas de revisiones tras cambios organizacionales comunicadas a la dirección ejecutiva.", "evidencia_en": "Review procedure and minutes of reviews after organizational changes communicated to executive management.", "limitaciones": "No verificable por escaneo de nube.", "limitaciones_en": "Not verifiable by cloud scanning.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.1", "5.4" ], "soc2_tsc": [ "CC3.4", "CC1.2" ], "cis_controls_v8": [] } }, { "id": 198, "numero_regla": "12.8.1", "requisito": "12", "seccion": "12.8", "categoria": "Requisito 12: Respaldar la seguridad de la información con políticas y programas organizacionales", "categoria_en": "Requirement 12: Support Information Security with Organizational Policies and Programs", "seccion_titulo": "Riesgo de proveedores de servicios externos (TPSP) gestionado", "seccion_titulo_en": "Risk to information assets from third-party service providers (TPSPs) is managed", "descripcion_corta": "Lista de proveedores de servicios externos (TPSP) con descripción de servicios", "descripcion_larga": "Se debe mantener una lista de todos los proveedores de servicios externos (TPSP) con los que se comparten datos de cuenta o que podrían afectar la seguridad de esos datos, con una descripción de cada servicio prestado. Usar un TPSP que cumple PCI DSS no hace que la entidad cumpla ni elimina su responsabilidad sobre su propio cumplimiento. El proveedor de nube (AWS, Azure o GCP) es un TPSP y debe figurar en la lista.", "remediacion": "1. Incluya al proveedor de nube como TPSP, detallando los servicios usados en el CDE (cómputo, bases de datos, KMS, CDN, etc.). 2. Agregue procesadores de pago, proveedores de SaaS de seguridad/monitoreo, MSP, soporte y cualquier tercero con acceso al CDE. 3. Use Kyber para descubrir terceros con acceso técnico: roles IAM con confianza a cuentas externas, delegaciones de Azure Lighthouse, usuarios invitados y principales de dominios externos en GCP, integraciones de Marketplace. 4. Revise la lista al menos anualmente y en cada alta o baja de proveedor. 5. Evidencia para el QSA: lista vigente de TPSP con descripción de servicios y responsable interno.", "descripcion_corta_en": "List of third-party service providers (TPSPs) with service descriptions", "descripcion_larga_en": "A list must be maintained of all third-party service providers (TPSPs) with which account data is shared or that could affect its security, with a description of each service provided. Using a PCI DSS compliant TPSP does not make the entity compliant nor remove its responsibility for its own compliance. The cloud provider (AWS, Azure, or GCP) is a TPSP and must be listed.", "remediacion_en": "1. List the cloud provider as a TPSP, detailing the services used in the CDE (compute, databases, KMS, CDN, etc.). 2. Add payment processors, security/monitoring SaaS providers, MSPs, support vendors, and any third party with CDE access. 3. Use Kyber to discover third parties with technical access: IAM roles trusting external accounts, Azure Lighthouse delegations, guest users, and external-domain principals in GCP, Marketplace integrations. 4. Review the list at least annually and whenever a provider is added or removed. 5. QSA evidence: current TPSP list with service descriptions and internal owner.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 319, "pagina_pdf_es": 335 }, "kyber_cobertura": { "tipo": "evidencia_generada", "automatizacion": "media", "checks_aws": [ "Roles IAM con políticas de confianza hacia cuentas AWS fuera de la organización (lista de terceros con acceso)", "Políticas de recursos (S3, KMS, SNS, SQS) que otorgan acceso a cuentas externas", "Usuarios de IAM Identity Center/SAML de proveedores externos con acceso a cuentas del CDE" ], "checks_azure": [ "Delegaciones de Azure Lighthouse sobre suscripciones del CDE", "Usuarios invitados (B2B) de Entra ID con roles en suscripciones del CDE", "Service principals de aplicaciones multi-inquilino de terceros con permisos en el CDE" ], "checks_gcp": [ "Bindings IAM a cuentas de usuario o de servicio de dominios externos en proyectos del CDE", "Cuentas de servicio de terceros con roles en proyectos del CDE" ], "evidencia": "Kyber genera el listado de terceros con acceso técnico a las cuentas del CDE y pre-carga al proveedor de nube como TPSP; el cliente completa la lista con descripciones de servicio y terceros sin acceso técnico.", "evidencia_en": "Kyber generates the list of third parties with technical access to CDE accounts and pre-loads the cloud provider as a TPSP; the customer completes the list with service descriptions and third parties without technical access.", "limitaciones": "Kyber no detecta TPSP sin integración técnica en la nube (p. ej., procesadores de pago, centros de llamadas).", "limitaciones_en": "Kyber does not detect TPSPs with no technical cloud integration (e.g., payment processors, call centers).", "responsabilidad_compartida": "cliente", "control_type": "hybrid", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.19", "5.22" ], "soc2_tsc": [ "CC9.2" ], "cis_controls_v8": [ "15.1" ], "banxico_spei": [ "61a." ] }, "mapeo_ucf": [ { "clave": "UCF-TPR-001", "relacion": "equivalent", "cobertura_pct": 80 } ] }, { "id": 199, "numero_regla": "12.8.2", "requisito": "12", "seccion": "12.8", "categoria": "Requisito 12: Respaldar la seguridad de la información con políticas y programas organizacionales", "categoria_en": "Requirement 12: Support Information Security with Organizational Policies and Programs", "seccion_titulo": "Riesgo de proveedores de servicios externos (TPSP) gestionado", "seccion_titulo_en": "Risk to information assets from third-party service providers (TPSPs) is managed", "descripcion_corta": "Acuerdos escritos con TPSP que reconocen su responsabilidad sobre los datos de cuenta", "descripcion_larga": "Se deben mantener acuerdos escritos con todos los TPSP con los que se comparten datos de cuenta o que podrían afectar la seguridad del CDE. Los acuerdos deben incluir el reconocimiento del TPSP de que es responsable de la seguridad de los datos de cuenta que posee, almacena, procesa o transmite en nombre de la entidad, o en la medida en que pueda afectar la seguridad de los datos del titular de la tarjeta y/o de los SAD de la entidad. La redacción exacta depende del servicio y puede referirse a otros documentos.", "remediacion": "1. Para el proveedor de nube, conserve el acuerdo de cliente vigente (AWS Customer Agreement, Microsoft Product Terms/DPA, Google Cloud Terms) y su documentación de responsabilidad PCI (AWS Artifact, Microsoft Service Trust Portal, Google Compliance Reports Manager). 2. Para otros TPSP, incluya una cláusula explícita de reconocimiento de responsabilidad PCI DSS, obligaciones de notificación de incidentes y derecho a solicitar evidencia de cumplimiento. 3. Mantenga un repositorio central de contratos vinculado a la lista de 12.8.1. 4. Evidencia para el QSA: contratos o anexos firmados con la cláusula de reconocimiento para cada TPSP de la lista.", "descripcion_corta_en": "Written agreements with TPSPs acknowledging responsibility for account data", "descripcion_larga_en": "Written agreements must be maintained with all TPSPs with which account data is shared or that could affect CDE security. Agreements must include the TPSP's acknowledgment that it is responsible for the security of account data it possesses, stores, processes, or transmits on the entity's behalf, or to the extent it could affect the security of the entity's cardholder data and/or SAD. Exact wording depends on the service and may reference other documents.", "remediacion_en": "1. For the cloud provider, retain the current customer agreement (AWS Customer Agreement, Microsoft Product Terms/DPA, Google Cloud Terms) and its PCI responsibility documentation (AWS Artifact, Microsoft Service Trust Portal, Google Compliance Reports Manager). 2. For other TPSPs, include an explicit PCI DSS responsibility acknowledgment clause, incident notification obligations, and the right to request compliance evidence. 3. Keep a central contract repository linked to the 12.8.1 list. 4. QSA evidence: signed contracts or addenda with the acknowledgment clause for every listed TPSP.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 320, "pagina_pdf_es": 336 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Contratos o anexos firmados con cláusula de reconocimiento de responsabilidad por cada TPSP; para el proveedor de nube, acuerdo vigente y documentación de AWS Artifact/Service Trust Portal/Compliance Reports Manager.", "evidencia_en": "Signed contracts or addenda with a responsibility acknowledgment clause for each TPSP; for the cloud provider, the current agreement and AWS Artifact/Service Trust Portal/Compliance Reports Manager documentation.", "limitaciones": "No verificable por escaneo de nube.", "limitaciones_en": "Not verifiable by cloud scanning.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.20" ], "soc2_tsc": [ "CC9.2" ], "cis_controls_v8": [ "15.4" ], "banxico_spei": [ "61a." ] } }, { "id": 200, "numero_regla": "12.8.3", "requisito": "12", "seccion": "12.8", "categoria": "Requisito 12: Respaldar la seguridad de la información con políticas y programas organizacionales", "categoria_en": "Requirement 12: Support Information Security with Organizational Policies and Programs", "seccion_titulo": "Riesgo de proveedores de servicios externos (TPSP) gestionado", "seccion_titulo_en": "Risk to information assets from third-party service providers (TPSPs) is managed", "descripcion_corta": "Proceso de contratación de TPSP con debida diligencia previa", "descripcion_larga": "Debe existir e implementarse un proceso establecido para contratar TPSP que incluya una debida diligencia adecuada antes de la contratación, para evaluar la capacidad, intención y recursos del proveedor para proteger los datos de cuenta.", "remediacion": "1. Defina un procedimiento de alta de proveedores con cuestionario de seguridad, revisión de su AOC de PCI DSS, alcance de los servicios evaluados y matriz de responsabilidades. 2. Para servicios de nube, verifique antes de usarlos en el CDE que estén listados en el alcance del AOC del proveedor (AWS Services in Scope, Azure/GCP PCI DSS scope). 3. Puede usar AWS Config/Azure Policy/Organization Policy para restringir servicios o regiones no aprobados en el CDE. 4. Registre la aprobación de seguridad previa a la firma. 5. Evidencia para el QSA: procedimiento y expedientes de debida diligencia de los TPSP recientes.", "descripcion_corta_en": "TPSP engagement process with prior due diligence", "descripcion_larga_en": "An established process must be implemented for engaging TPSPs that includes proper due diligence before engagement, to assess the provider's capability, intent, and resources to protect account data.", "remediacion_en": "1. Define a vendor onboarding procedure with a security questionnaire, review of the PCI DSS AOC, scope of assessed services, and responsibility matrix. 2. For cloud services, verify before using them in the CDE that they are within the provider's AOC scope (AWS Services in Scope, Azure/GCP PCI DSS scope). 3. You can use AWS SCPs/Azure Policy/Organization Policy to restrict unapproved services or regions in the CDE. 4. Record security approval prior to signing. 5. QSA evidence: procedure and due diligence files for recent TPSPs.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 322, "pagina_pdf_es": 338 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Procedimiento de contratación y expedientes de debida diligencia (cuestionarios, AOC revisados, aprobaciones).", "evidencia_en": "Engagement procedure and due diligence files (questionnaires, reviewed AOCs, approvals).", "limitaciones": "No verificable por escaneo de nube.", "limitaciones_en": "Not verifiable by cloud scanning.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.19" ], "soc2_tsc": [ "CC9.2" ], "cis_controls_v8": [ "15.5" ] } }, { "id": 201, "numero_regla": "12.8.4", "requisito": "12", "seccion": "12.8", "categoria": "Requisito 12: Respaldar la seguridad de la información con políticas y programas organizacionales", "categoria_en": "Requirement 12: Support Information Security with Organizational Policies and Programs", "seccion_titulo": "Riesgo de proveedores de servicios externos (TPSP) gestionado", "seccion_titulo_en": "Risk to information assets from third-party service providers (TPSPs) is managed", "descripcion_corta": "Programa de monitoreo anual del estado de cumplimiento PCI DSS de los TPSP", "descripcion_larga": "Se debe implementar un programa para monitorear el estado de cumplimiento de PCI DSS de los TPSP al menos una vez cada 12 meses. Cuando un TPSP ofrece varios servicios, el estado monitoreado debe corresponder a los servicios prestados a la entidad.", "remediacion": "1. Solicite anualmente a cada TPSP su AOC vigente (o evidencia equivalente) y verifique fechas y servicios cubiertos. 2. Para el proveedor de nube descargue cada año el AOC/ROC de PCI DSS: AWS Artifact, Microsoft Service Trust Portal o Google Compliance Reports Manager, y confirme que los servicios usados en el CDE estén en alcance. 3. Registre el estado en un tablero de TPSP con alertas de vencimiento. 4. Defina acciones si un TPSP pierde su cumplimiento. 5. Evidencia para el QSA: AOC vigentes de cada TPSP y registro de revisión anual.", "descripcion_corta_en": "Annual program to monitor TPSPs' PCI DSS compliance status", "descripcion_larga_en": "A program must be implemented to monitor TPSPs' PCI DSS compliance status at least once every 12 months. Where a TPSP offers several services, the monitored status should correspond to the services delivered to the entity.", "remediacion_en": "1. Request each TPSP's current AOC (or equivalent evidence) annually and check dates and services covered. 2. For the cloud provider, download the PCI DSS AOC/ROC every year from AWS Artifact, Microsoft Service Trust Portal, or Google Compliance Reports Manager, and confirm CDE services are in scope. 3. Track status in a TPSP dashboard with expiry alerts. 4. Define actions if a TPSP loses compliance. 5. QSA evidence: current AOCs for every TPSP and an annual review log.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 323, "pagina_pdf_es": 339 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "AOC vigentes de cada TPSP (incluido el del proveedor de nube desde AWS Artifact, Service Trust Portal o Compliance Reports Manager) y registro de revisión anual; Kyber puede comparar los servicios de nube en uso contra la lista de servicios en alcance del AOC del proveedor.", "evidencia_en": "Current AOCs for each TPSP (including the cloud provider's from AWS Artifact, Service Trust Portal, or Compliance Reports Manager) and an annual review log; Kyber can compare cloud services in use against the provider's AOC in-scope service list.", "limitaciones": "Kyber no obtiene ni valida los AOC de terceros; solo puede contrastar servicios de nube en uso con el alcance publicado del proveedor.", "limitaciones_en": "Kyber does not obtain or validate third-party AOCs; it can only compare cloud services in use against the provider's published scope.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.22" ], "soc2_tsc": [ "CC9.2" ], "cis_controls_v8": [ "15.6" ] } }, { "id": 202, "numero_regla": "12.8.5", "requisito": "12", "seccion": "12.8", "categoria": "Requisito 12: Respaldar la seguridad de la información con políticas y programas organizacionales", "categoria_en": "Requirement 12: Support Information Security with Organizational Policies and Programs", "seccion_titulo": "Riesgo de proveedores de servicios externos (TPSP) gestionado", "seccion_titulo_en": "Risk to information assets from third-party service providers (TPSPs) is managed", "descripcion_corta": "Matriz de requisitos PCI DSS gestionados por cada TPSP, por la entidad o compartidos", "descripcion_larga": "Se debe mantener información sobre qué requisitos de PCI DSS gestiona cada TPSP, cuáles gestiona la entidad y cuáles se comparten entre ambos, incluidos los componentes del sistema relacionados. Para el proveedor de nube, esta información se documenta en su matriz de responsabilidad compartida.", "remediacion": "1. Obtenga la matriz de responsabilidades PCI DSS del proveedor de nube (AWS PCI DSS Responsibility Summary en AWS Artifact, Azure PCI DSS shared responsibility matrix en Service Trust Portal, Google Cloud PCI DSS shared responsibility matrix) y adáptela a los servicios usados. 2. Construya una matriz por TPSP con cada requisito marcado como TPSP/entidad/compartido y detalle de cómo se reparte lo compartido. 3. Vincule la matriz a los controles de Kyber para mostrar qué checks cubren la parte del cliente. 4. Revísela anualmente y ante cambios de servicio. 5. Evidencia para el QSA: matrices de responsabilidad por TPSP vigentes.", "descripcion_corta_en": "Matrix of PCI DSS requirements managed by each TPSP, by the entity, or shared", "descripcion_larga_en": "Information must be maintained on which PCI DSS requirements each TPSP manages, which the entity manages, and which are shared between them, including related system components. For the cloud provider, this is documented in its shared responsibility matrix.", "remediacion_en": "1. Obtain the cloud provider's PCI DSS responsibility matrix (AWS PCI DSS Responsibility Summary in AWS Artifact, Azure PCI DSS shared responsibility matrix in the Service Trust Portal, Google Cloud PCI DSS shared responsibility matrix) and tailor it to the services used. 2. Build a matrix per TPSP marking each requirement as TPSP/entity/shared, detailing how shared items are split. 3. Link the matrix to Kyber controls to show which checks cover the customer's portion. 4. Review it annually and when services change. 5. QSA evidence: current responsibility matrices per TPSP.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 325, "pagina_pdf_es": 340 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Matrices de responsabilidad por TPSP; para el proveedor de nube, su matriz oficial de responsabilidad compartida PCI DSS; Kyber marca en su catálogo la responsabilidad (cliente/proveedor_nube/compartida) de cada requisito.", "evidencia_en": "Responsibility matrices per TPSP; for the cloud provider, its official PCI DSS shared responsibility matrix; Kyber's catalog flags responsibility (customer/cloud provider/shared) for each requirement.", "limitaciones": "No verificable por escaneo; Kyber solo aporta la referencia de responsabilidad por requisito.", "limitaciones_en": "Not verifiable by scanning; Kyber only provides the per-requirement responsibility reference.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.20", "5.23" ], "soc2_tsc": [ "CC9.2" ], "cis_controls_v8": [ "15.4" ] } }, { "id": 203, "numero_regla": "12.9.1", "requisito": "12", "seccion": "12.9", "categoria": "Requisito 12: Respaldar la seguridad de la información con políticas y programas organizacionales", "categoria_en": "Requirement 12: Support Information Security with Organizational Policies and Programs", "seccion_titulo": "Los TPSP apoyan el cumplimiento de PCI DSS de sus clientes", "seccion_titulo_en": "TPSPs support their customers' PCI DSS compliance", "descripcion_corta": "Los TPSP reconocen por escrito ante sus clientes su responsabilidad sobre los datos de cuenta", "descripcion_larga": "Requisito adicional solo para proveedores de servicios: los TPSP deben proporcionar a sus clientes acuerdos escritos que incluyan el reconocimiento de que son responsables de la seguridad de los datos de cuenta que poseen, almacenan, procesan o transmiten en nombre del cliente, o en la medida en que puedan afectar la seguridad de los datos del titular de la tarjeta y/o SAD del cliente. La redacción exacta no tiene que coincidir con la del requisito y puede depender del servicio y de las responsabilidades asignadas.", "remediacion": "1. Incluya en los contratos o términos de servicio con clientes una cláusula de reconocimiento de responsabilidad PCI DSS acorde al servicio prestado. 2. Mantenga plantillas aprobadas por el área legal y un registro de contratos firmados. 3. Si opera sobre AWS/Azure/GCP, indique qué responsabilidades hereda del proveedor de nube y cuáles asume ante el cliente. 4. Evidencia para el QSA: políticas, plantillas de contrato y muestras de acuerdos firmados.", "descripcion_corta_en": "TPSPs acknowledge in writing to customers their responsibility for account data", "descripcion_larga_en": "Additional requirement for service providers only: TPSPs must provide customers with written agreements acknowledging they are responsible for the security of account data they possess, store, process, or transmit on the customer's behalf, or to the extent they could affect the security of the customer's cardholder data and/or SAD. Exact wording need not match the requirement and may depend on the service and assigned responsibilities.", "remediacion_en": "1. Include a PCI DSS responsibility acknowledgment clause suited to the service in customer contracts or terms of service. 2. Keep legal-approved templates and a register of signed contracts. 3. If you run on AWS/Azure/GCP, state which responsibilities are inherited from the cloud provider and which you assume toward the customer. 4. QSA evidence: policies, contract templates, and samples of signed agreements.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 327, "pagina_pdf_es": 342 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Plantillas de contrato con la cláusula de reconocimiento y muestras de acuerdos firmados con clientes.", "evidencia_en": "Contract templates with the acknowledgment clause and samples of signed customer agreements.", "limitaciones": "No verificable por escaneo de nube.", "limitaciones_en": "Not verifiable by cloud scanning.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.20" ], "soc2_tsc": [ "CC9.2", "CC2.3" ], "cis_controls_v8": [] } }, { "id": 204, "numero_regla": "12.9.2", "requisito": "12", "seccion": "12.9", "categoria": "Requisito 12: Respaldar la seguridad de la información con políticas y programas organizacionales", "categoria_en": "Requirement 12: Support Information Security with Organizational Policies and Programs", "seccion_titulo": "Los TPSP apoyan el cumplimiento de PCI DSS de sus clientes", "seccion_titulo_en": "TPSPs support their customers' PCI DSS compliance", "descripcion_corta": "Los TPSP proporcionan a sus clientes estado de cumplimiento y matriz de responsabilidades", "descripcion_larga": "Requisito adicional solo para proveedores de servicios: los TPSP deben apoyar las solicitudes de sus clientes para cumplir los Requisitos 12.8.4 y 12.8.5, entregando cuando se les pida información sobre su estado de cumplimiento de PCI DSS e información sobre qué requisitos son responsabilidad del TPSP, cuáles del cliente y cuáles se comparten, para cualquier servicio que cumpla requisitos en nombre del cliente o que pueda afectar la seguridad de sus datos del titular de la tarjeta o SAD.", "remediacion": "1. Publique o entregue bajo solicitud su AOC vigente (p. ej., en un portal de confianza similar a AWS Artifact o Service Trust Portal). 2. Elabore y mantenga una matriz de responsabilidades PCI DSS por servicio, indicando con detalle cómo se reparten los requisitos compartidos. 3. Defina un procedimiento y SLA para responder solicitudes de clientes. 4. Evidencia para el QSA: procedimiento, AOC vigente, matriz publicada y registro de solicitudes atendidas.", "descripcion_corta_en": "TPSPs provide customers with compliance status and responsibility matrix", "descripcion_larga_en": "Additional requirement for service providers only: TPSPs must support customers' requests to meet Requirements 12.8.4 and 12.8.5 by providing, upon request, their PCI DSS compliance status and information about which requirements are the TPSP's responsibility, which are the customer's, and which are shared, for any service that meets requirements on the customer's behalf or can affect the security of the customer's cardholder data or SAD.", "remediacion_en": "1. Publish or provide on request your current AOC (e.g., via a trust portal similar to AWS Artifact or Service Trust Portal). 2. Build and maintain a PCI DSS responsibility matrix per service, detailing how shared requirements are split. 3. Define a procedure and SLA for responding to customer requests. 4. QSA evidence: procedure, current AOC, published matrix, and a log of handled requests.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 329, "pagina_pdf_es": 344 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "AOC vigente, matriz de responsabilidades por servicio y registro de solicitudes de clientes atendidas.", "evidencia_en": "Current AOC, per-service responsibility matrix, and a log of handled customer requests.", "limitaciones": "No verificable por escaneo de nube.", "limitaciones_en": "Not verifiable by cloud scanning.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.20", "5.23" ], "soc2_tsc": [ "CC9.2", "CC2.3" ], "cis_controls_v8": [] } }, { "id": 205, "numero_regla": "12.10.1", "requisito": "12", "seccion": "12.10", "categoria": "Requisito 12: Respaldar la seguridad de la información con políticas y programas organizacionales", "categoria_en": "Requirement 12: Support Information Security with Organizational Policies and Programs", "seccion_titulo": "Respuesta inmediata a incidentes de seguridad que afecten al CDE", "seccion_titulo_en": "Security incidents that could impact the CDE are responded to immediately", "descripcion_corta": "Plan de respuesta a incidentes listo para activarse ante incidentes de seguridad", "descripcion_larga": "Debe existir un plan de respuesta a incidentes listo para activarse ante un incidente de seguridad sospechado o confirmado. Debe incluir al menos: roles, responsabilidades y estrategias de comunicación y contacto, incluida la notificación a las marcas de pago y adquirentes; procedimientos de respuesta con actividades específicas de contención y mitigación por tipo de incidente; procedimientos de recuperación y continuidad del negocio; procesos de respaldo de datos; análisis de los requisitos legales de notificación de compromisos; cobertura y respuesta de todos los componentes críticos; y referencia o inclusión de los procedimientos de respuesta de las marcas de pago.", "remediacion": "1. Redacte el plan (o genérelo con Kyber) siguiendo NIST SP 800-61, con roles, árbol de contactos y plantillas de notificación a marcas, adquirentes y autoridades (considere la LFPDPPP en México, GDPR, etc.). 2. Incluya playbooks específicos de nube: credenciales IAM comprometidas, instancia comprometida (aislar con security group de cuarentena, snapshot forense), bucket expuesto, compromiso de llaves KMS, ransomware. 3. Integre respaldos (AWS Backup, Azure Backup, Backup and DR) y recuperación entre regiones/cuentas. 4. Prepare cuentas o roles de respuesta forense ('break-glass') y herramientas (Amazon Detective, Microsoft Sentinel, Chronicle/SCC). 5. Referencie los procedimientos de las marcas de pago (Visa, Mastercard, etc.). 6. Evidencia para el QSA: plan vigente aprobado y registros de incidentes o alertas previas donde se siguió.", "descripcion_corta_en": "Incident response plan ready to activate for security incidents", "descripcion_larga_en": "An incident response plan must exist and be ready to activate for a suspected or confirmed security incident. It must include at least: roles, responsibilities, and communication and contact strategies, including notification of payment brands and acquirers; response procedures with specific containment and mitigation activities by incident type; business recovery and continuity procedures; data backup processes; analysis of legal requirements for reporting compromises; coverage and response for all critical components; and reference to or inclusion of payment brands' incident response procedures.", "remediacion_en": "1. Write the plan (or generate it with Kyber) following NIST SP 800-61, with roles, contact tree, and notification templates for brands, acquirers, and authorities (consider Mexico's LFPDPPP, GDPR, etc.). 2. Include cloud-specific playbooks: compromised IAM credentials, compromised instance (isolate with a quarantine security group, forensic snapshot), exposed bucket, KMS key compromise, ransomware. 3. Integrate backups (AWS Backup, Azure Backup, Backup and DR) and cross-region/cross-account recovery. 4. Prepare forensic response accounts or roles (break-glass) and tooling (Amazon Detective, Microsoft Sentinel, Chronicle/SCC). 5. Reference payment brand procedures (Visa, Mastercard, etc.). 6. QSA evidence: current approved plan and records of past incidents or alerts where it was followed.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 331, "pagina_pdf_es": 346 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Plan de respuesta a incidentes aprobado con todos los elementos y playbooks de nube; registros de incidentes o alertas atendidas; Kyber puede generar la plantilla del plan.", "evidencia_en": "Approved incident response plan with all elements and cloud playbooks; records of handled incidents or alerts; Kyber can generate the plan template.", "limitaciones": "El escaneo no puede validar que el plan esté listo ni que se haya seguido; requiere revisión documental y entrevistas.", "limitaciones_en": "Scanning cannot validate that the plan is ready or was followed; documentary review and interviews are required.", "responsabilidad_compartida": "cliente", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.24", "5.26", "5.29" ], "soc2_tsc": [ "CC7.3", "CC7.4", "CC7.5" ], "cis_controls_v8": [ "17.4" ], "banxico_spei": [ "46a.", "58a. I.A.b).5", "58a. I.B.g)", "58a. II.a).2", "58a. II.c)" ] }, "mapeo_ucf": [ { "clave": "UCF-INC-001", "relacion": "equivalent", "cobertura_pct": 100 } ] }, { "id": 206, "numero_regla": "12.10.5", "requisito": "12", "seccion": "12.10", "categoria": "Requisito 12: Respaldar la seguridad de la información con políticas y programas organizacionales", "categoria_en": "Requirement 12: Support Information Security with Organizational Policies and Programs", "seccion_titulo": "Respuesta inmediata a incidentes de seguridad que afecten al CDE", "seccion_titulo_en": "Security incidents that could impact the CDE are responded to immediately", "descripcion_corta": "Plan de respuesta incluye monitoreo y respuesta a alertas de sistemas de seguridad", "descripcion_larga": "El plan de respuesta a incidentes debe incluir el monitoreo y la respuesta a las alertas generadas por los sistemas de monitoreo de seguridad, incluyendo, entre otros: sistemas de detección y prevención de intrusiones, controles de seguridad de la red (NSC), mecanismos de detección de cambios en archivos críticos, el mecanismo de detección de cambios y manipulación de páginas de pago (obligatorio desde el 31 de marzo de 2025) y la detección de puntos de acceso inalámbricos no autorizados.", "remediacion": "1. Centralice hallazgos: AWS Security Hub (agregando GuardDuty, Inspector, Macie, Network Firewall, FIM), Microsoft Defender for Cloud/Sentinel o Security Command Center. 2. Cree reglas de enrutamiento: EventBridge → SNS/Chatbot/SIEM para hallazgos de GuardDuty y Security Hub con severidad ≥ media; en Azure, Workflow automation/Logic Apps o reglas de análisis de Sentinel; en GCP, notificaciones de SCC a Pub/Sub. 3. Documente en el plan cada fuente de alerta (IDS/IPS, NSC como Network Firewall/Azure Firewall/Cloud NGFW, FIM, monitoreo de páginas de pago, WIDS si aplica) con su playbook y responsable de guardia. 4. Pruebe el flujo de alertas periódicamente. 5. Evidencia para el QSA: sección del plan, configuración de enrutamiento y alertas atendidas.", "descripcion_corta_en": "Incident response plan covers monitoring and response to security system alerts", "descripcion_larga_en": "The incident response plan must include monitoring and responding to alerts from security monitoring systems, including but not limited to: intrusion-detection and prevention systems, network security controls (NSCs), change-detection mechanisms for critical files, the payment page change- and tamper-detection mechanism (mandatory from 31 March 2025), and detection of unauthorized wireless access points.", "remediacion_en": "1. Centralize findings: AWS Security Hub (aggregating GuardDuty, Inspector, Macie, Network Firewall, FIM), Microsoft Defender for Cloud/Sentinel, or Security Command Center. 2. Create routing rules: EventBridge -> SNS/Chatbot/SIEM for GuardDuty and Security Hub findings of medium severity or higher; in Azure, workflow automation/Logic Apps or Sentinel analytics rules; in GCP, SCC notifications to Pub/Sub. 3. Document in the plan each alert source (IDS/IPS, NSCs such as Network Firewall/Azure Firewall/Cloud NGFW, FIM, payment page monitoring, WIDS if applicable) with its playbook and on-call owner. 4. Test the alert flow periodically. 5. QSA evidence: plan section, routing configuration, and handled alerts.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 335, "pagina_pdf_es": 350 }, "kyber_cobertura": { "tipo": "deteccion_presencia", "automatizacion": "media", "checks_aws": [ "AWS Security Hub habilitado en todas las cuentas y regiones del CDE [SecurityHub.1]", "Regla de EventBridge para hallazgos de GuardDuty/Security Hub con destino SNS, Lambda o SIEM (falla si no existe)", "Tema SNS de alertas de seguridad con al menos una suscripción confirmada", "AWS Network Firewall y WAF con registro hacia CloudWatch Logs/S3 para alimentar alertas" ], "checks_azure": [ "Microsoft Defender for Cloud con automatización de flujo de trabajo o exportación continua de alertas a Log Analytics/Sentinel (falla si no existe)", "Contactos de seguridad de Defender for Cloud configurados con notificación de alertas de severidad alta", "Microsoft Sentinel con reglas de análisis activas sobre fuentes de IDS/firewall" ], "checks_gcp": [ "Notificaciones de Security Command Center configuradas hacia un tema de Pub/Sub (falla si no existen)", "Políticas de alertas de Cloud Monitoring con canales de notificación para hallazgos de seguridad", "Registro de Cloud IDS/Cloud NGFW enviado a Cloud Logging" ], "evidencia": "Kyber verifica la existencia del enrutamiento de alertas de seguridad hacia canales de respuesta; el cliente aporta la sección del plan y evidencia de alertas atendidas.", "evidencia_en": "Kyber verifies that security alert routing to response channels exists; the customer provides the plan section and evidence of handled alerts.", "limitaciones": "Kyber no puede verificar que las alertas se atiendan efectivamente ni la detección de puntos de acceso inalámbricos o de manipulación de páginas de pago fuera de la nube.", "limitaciones_en": "Kyber cannot verify that alerts are actually handled, nor wireless access point or payment page tamper detection outside the cloud.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.25", "8.16" ], "soc2_tsc": [ "CC7.3" ], "cis_controls_v8": [ "13.1", "17.4" ], "banxico_spei": [ "46a." ] } }, { "id": 207, "numero_regla": "12.10.7", "requisito": "12", "seccion": "12.10", "categoria": "Requisito 12: Respaldar la seguridad de la información con políticas y programas organizacionales", "categoria_en": "Requirement 12: Support Information Security with Organizational Policies and Programs", "seccion_titulo": "Respuesta inmediata a incidentes de seguridad que afecten al CDE", "seccion_titulo_en": "Security incidents that could impact the CDE are responded to immediately", "descripcion_corta": "Procedimientos de respuesta ante PAN almacenado en ubicaciones no esperadas", "descripcion_larga": "Deben existir procedimientos de respuesta a incidentes que se inicien al detectar PAN almacenado en cualquier lugar donde no se espera. Deben incluir: qué hacer si se encuentra PAN fuera del CDE (recuperación, eliminación segura y/o migración al CDE definido); determinar si se almacenan SAD junto con el PAN; identificar de dónde provienen los datos y cómo llegaron a esa ubicación; y remediar las fugas de datos o deficiencias de proceso que lo causaron.", "remediacion": "1. Active descubrimiento automático de datos sensibles: Amazon Macie (descubrimiento automático y trabajos sobre buckets fuera del CDE), Microsoft Purview/Defender for Storage (detección de datos confidenciales) o Sensitive Data Protection discovery en GCP, incluyendo bases de datos y snapshots. 2. Enrute hallazgos de tipo número de tarjeta de crédito a la guardia de seguridad (EventBridge/Logic Apps/Pub/Sub). 3. Documente un playbook: contención (bloquear acceso al bucket/recurso), verificación de SAD, eliminación segura o migración al CDE, análisis de causa raíz (origen y flujo) y corrección del proceso. 4. Revise el alcance (12.5.2) cuando se encuentren datos fuera del CDE. 5. Evidencia para el QSA: procedimiento y registros de acciones de respuesta ejecutadas.", "descripcion_corta_en": "Response procedures for PAN stored in unexpected locations", "descripcion_larga_en": "Incident response procedures must exist and be initiated upon detecting stored PAN anywhere it is not expected. They must include: what to do if PAN is found outside the CDE (retrieval, secure deletion, and/or migration into the defined CDE); determining whether SAD is stored with the PAN; identifying where the data came from and how it got there; and remediating the data leaks or process gaps that caused it.", "remediacion_en": "1. Enable automated sensitive data discovery: Amazon Macie (automated discovery and jobs on buckets outside the CDE), Microsoft Purview/Defender for Storage (sensitive data threat detection), or GCP Sensitive Data Protection discovery, including databases and snapshots. 2. Route credit-card-number findings to the security on-call (EventBridge/Logic Apps/Pub/Sub). 3. Document a playbook: containment (block access to the bucket/resource), SAD check, secure deletion or migration into the CDE, root-cause analysis (origin and flow), and process correction. 4. Review scope (12.5.2) when data is found outside the CDE. 5. QSA evidence: procedure and records of response actions taken.", "aplica_a": "todas_las_entidades", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 337, "pagina_pdf_es": 352 }, "kyber_cobertura": { "tipo": "deteccion_presencia", "automatizacion": "media", "checks_aws": [ "Amazon Macie habilitado en todas las cuentas y regiones [Macie.1]", "Descubrimiento automático de datos sensibles de Macie habilitado [Macie.2]", "Regla de EventBridge que enruta hallazgos de Macie (SensitiveData:S3Object/Financial) a SNS/SIEM (falla si no existe)", "Hallazgos de Macie con datos de tarjeta en buckets fuera de cuentas del CDE (falla si existen)" ], "checks_azure": [ "Defender for Storage con detección de amenazas de datos confidenciales (sensitive data threat detection) habilitada", "Microsoft Purview Data Map con escaneos y clasificación de tarjetas de crédito sobre cuentas de almacenamiento y bases de datos", "Recursos fuera del CDE con clasificación de número de tarjeta detectada (falla si existen)" ], "checks_gcp": [ "Sensitive Data Protection con configuración de descubrimiento (discovery) a nivel de organización o proyecto", "Perfiles de datos con infoType CREDIT_CARD_NUMBER en recursos fuera del CDE (falla si existen)", "Publicación de perfiles/hallazgos de Sensitive Data Protection a Pub/Sub o SCC" ], "evidencia": "Kyber verifica la presencia de descubrimiento de PAN y enrutamiento de alertas, y reporta hallazgos de PAN fuera del CDE; el cliente aporta el procedimiento de respuesta y registros de acciones.", "evidencia_en": "Kyber verifies that PAN discovery and alert routing are present and reports PAN found outside the CDE; the customer provides the response procedure and action records.", "limitaciones": "La cobertura de descubrimiento depende de las fuentes configuradas (p. ej., Macie solo cubre S3); no se detecta PAN en endpoints u on-premises.", "limitaciones_en": "Discovery coverage depends on configured sources (e.g., Macie only covers S3); PAN on endpoints or on-premises is not detected.", "responsabilidad_compartida": "cliente", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.26", "8.12" ], "soc2_tsc": [ "CC7.4" ], "cis_controls_v8": [ "3.13", "17.4" ] } }, { "id": 208, "numero_regla": "A1.1.1", "requisito": "A1", "seccion": "A1.1", "categoria": "Anexo A1: requisitos adicionales para proveedores de servicios multiusuario", "categoria_en": "Appendix A1: Additional PCI DSS Requirements for Multi-Tenant Service Providers", "seccion_titulo": "Proveedores multiusuario protegen y separan los entornos de sus clientes", "seccion_titulo_en": "Multi-tenant service providers protect and separate customer environments", "descripcion_corta": "Separación lógica entre el entorno del proveedor multi-tenant y los de sus clientes", "descripcion_larga": "Requisito para proveedores de servicios multi-tenant: se debe implementar separación lógica de modo que el proveedor no pueda acceder a los entornos de sus clientes sin autorización, y que los clientes no puedan acceder al entorno del proveedor sin autorización.", "remediacion": "1. Aloje a cada cliente en cuentas/suscripciones/proyectos dedicados, separados de las cuentas de administración del proveedor (AWS Organizations OU por cliente, grupos de administración de Azure, carpetas de GCP). 2. Restrinja el acceso del proveedor a los entornos de clientes mediante roles de acceso just-in-time con aprobación (IAM Identity Center con permisos temporales, Entra PIM, Privileged Access Manager de GCP) y registre cada acceso. 3. Impida que identidades de clientes tengan permisos en cuentas del proveedor (SCP, Azure Policy, Organization Policy con restricción de dominios). 4. Aísle la red: sin peerings ni rutas entre VPC de clientes y del plano de gestión salvo endpoints controlados. 5. Evidencia para el QSA: arquitectura de tenencia, políticas de acceso, registros de aprobaciones y configuración de red.", "descripcion_corta_en": "Logical separation between the multi-tenant provider's environment and its customers'", "descripcion_larga_en": "Requirement for multi-tenant service providers: logical separation must be implemented so that the provider cannot access its customers' environments without authorization, and customers cannot access the provider's environment without authorization.", "remediacion_en": "1. Host each customer in dedicated accounts/subscriptions/projects separated from the provider's management accounts (AWS Organizations OU per customer, Azure management groups, GCP folders). 2. Restrict provider access to customer environments through approved just-in-time roles (IAM Identity Center with temporary permissions, Entra PIM, GCP Privileged Access Manager) and log every access. 3. Prevent customer identities from having permissions in provider accounts (SCPs, Azure Policy, Organization Policy domain restriction). 4. Isolate networking: no peerings or routes between customer VPCs and the management plane except controlled endpoints. 5. QSA evidence: tenancy architecture, access policies, approval logs, and network configuration.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 340, "pagina_pdf_es": 354 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Roles IAM en cuentas de clientes con confianza hacia cuentas del proveedor sin condiciones (p. ej., sin aws:PrincipalOrgID o sts:ExternalId) (falla si existen)", "Roles o políticas de recursos en cuentas del proveedor que confían en principales de cuentas de clientes (falla si existen)", "VPC peerings o rutas de Transit Gateway entre VPC de clientes y VPC de gestión del proveedor no aprobados (falla si existen)", "SCP aplicadas a las OU de clientes que restringen acceso entre cuentas" ], "checks_azure": [ "Asignaciones de roles RBAC de identidades del proveedor en suscripciones de clientes sin PIM (asignaciones permanentes) (falla si existen)", "Identidades de inquilinos de clientes con roles en suscripciones del proveedor (falla si existen)", "VNet peerings entre VNet de clientes y del proveedor no aprobados (falla si existen)" ], "checks_gcp": [ "Bindings IAM permanentes de principales del proveedor en proyectos de clientes (falla si existen)", "Organization Policy iam.allowedPolicyMemberDomains aplicada en carpetas de clientes", "VPC peerings o Shared VPC entre proyectos de clientes y del proveedor no aprobados (falla si existen)" ], "evidencia": "Kyber verifica relaciones de confianza IAM, asignaciones de roles y conectividad de red entre cuentas de clientes y del proveedor; el cliente aporta la arquitectura de tenencia y registros de accesos autorizados.", "evidencia_en": "Kyber verifies IAM trust relationships, role assignments, and network connectivity between customer and provider accounts; the customer provides the tenancy architecture and authorized-access logs.", "limitaciones": "Kyber no puede validar la separación en capas de aplicación compartidas (p. ej., bases de datos multi-tenant) ni que los accesos fueron autorizados.", "limitaciones_en": "Kyber cannot validate separation in shared application layers (e.g., multi-tenant databases) or that accesses were authorized.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.22", "5.15", "8.2" ], "soc2_tsc": [ "CC6.1", "CC6.3" ], "cis_controls_v8": [ "12.2", "6.8" ] } }, { "id": 209, "numero_regla": "A1.1.2", "requisito": "A1", "seccion": "A1.1", "categoria": "Anexo A1: requisitos adicionales para proveedores de servicios multiusuario", "categoria_en": "Appendix A1: Additional PCI DSS Requirements for Multi-Tenant Service Providers", "seccion_titulo": "Proveedores multiusuario protegen y separan los entornos de sus clientes", "seccion_titulo_en": "Multi-tenant service providers protect and separate customer environments", "descripcion_corta": "Cada cliente solo puede acceder a sus propios datos del titular de la tarjeta y su CDE", "descripcion_larga": "Requisito para proveedores de servicios multi-tenant: se deben implementar controles para que cada cliente solo tenga permiso de acceder a sus propios datos del titular de la tarjeta y a su propio CDE, evitando el acceso no autorizado de un cliente al entorno de otro.", "remediacion": "1. Use cuentas/suscripciones/proyectos dedicados por cliente y, si comparte servicios, aísle datos por inquilino con llaves de cifrado por cliente (KMS/Key Vault/Cloud KMS por tenant), políticas de recursos y etiquetas de sesión ABAC. 2. Federar identidades de clientes con alcance limitado a sus recursos (permission sets por cliente, Entra B2B con RBAC por grupo de recursos, IAM conditions en GCP). 3. Aplique barreras preventivas (SCP, Azure Policy, Organization Policy) que nieguen acceso entre inquilinos. 4. Revise periódicamente los permisos efectivos (IAM Access Analyzer, Entra access reviews, Policy Analyzer). 5. Evidencia para el QSA: diseño de control de acceso por inquilino y configuraciones que demuestren el aislamiento.", "descripcion_corta_en": "Each customer can only access its own cardholder data and CDE", "descripcion_larga_en": "Requirement for multi-tenant service providers: controls must be implemented so that each customer only has permission to access its own cardholder data and CDE, preventing unauthorized access from one customer's environment to another's.", "remediacion_en": "1. Use dedicated accounts/subscriptions/projects per customer and, where services are shared, isolate data per tenant with customer-specific encryption keys (KMS/Key Vault/Cloud KMS per tenant), resource policies, and ABAC session tags. 2. Federate customer identities scoped to their own resources (per-customer permission sets, Entra B2B with resource-group RBAC, GCP IAM conditions). 3. Apply preventive guardrails (SCPs, Azure Policy, Organization Policy) that deny cross-tenant access. 4. Periodically review effective permissions (IAM Access Analyzer, Entra access reviews, Policy Analyzer). 5. QSA evidence: per-tenant access control design and configurations demonstrating isolation.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "crit", "referencia_documento": { "pagina_pdf_en": 341, "pagina_pdf_es": 355 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "IAM Access Analyzer habilitado a nivel de organización; hallazgos de acceso externo entre cuentas de clientes (falla si existen)", "Políticas de bucket S3 o llaves KMS de un cliente que otorgan acceso a cuentas de otros clientes (falla si existen)", "Llaves KMS compartidas entre inquilinos para datos de tarjeta (falla si existen)" ], "checks_azure": [ "Asignaciones RBAC de identidades de un cliente sobre suscripciones/grupos de recursos de otro cliente (falla si existen)", "Key Vault o cuentas de almacenamiento con políticas de acceso que incluyen identidades de otros inquilinos (falla si existen)" ], "checks_gcp": [ "Bindings IAM de principales de un cliente en proyectos de otro cliente (falla si existen)", "Buckets o llaves Cloud KMS con acceso concedido a principales de otros inquilinos (falla si existen)" ], "evidencia": "Kyber analiza permisos efectivos y políticas de recursos entre cuentas de inquilinos y reporta accesos cruzados; el cliente aporta el diseño de control de acceso por inquilino.", "evidencia_en": "Kyber analyzes effective permissions and resource policies across tenant accounts and reports cross-access; the customer provides the per-tenant access control design.", "limitaciones": "No cubre el aislamiento lógico implementado en el código de aplicaciones multi-tenant.", "limitaciones_en": "Does not cover logical isolation implemented in multi-tenant application code.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "5.15", "8.3" ], "soc2_tsc": [ "CC6.1", "CC6.3" ], "cis_controls_v8": [ "3.3", "6.8" ] } }, { "id": 210, "numero_regla": "A1.1.3", "requisito": "A1", "seccion": "A1.1", "categoria": "Anexo A1: requisitos adicionales para proveedores de servicios multiusuario", "categoria_en": "Appendix A1: Additional PCI DSS Requirements for Multi-Tenant Service Providers", "seccion_titulo": "Proveedores multiusuario protegen y separan los entornos de sus clientes", "seccion_titulo_en": "Multi-tenant service providers protect and separate customer environments", "descripcion_corta": "Cada cliente solo puede acceder a los recursos asignados a él", "descripcion_larga": "Requisito para proveedores de servicios multi-tenant: se deben implementar controles para que cada cliente solo pueda acceder a los recursos que le fueron asignados, evitando que impacte de forma intencional o inadvertida los recursos asignados a otros clientes.", "remediacion": "1. Asigne recursos de cómputo, almacenamiento y red por cliente (cuentas/suscripciones/proyectos o namespaces dedicados) con cuotas y límites (Service Quotas, cuotas de Azure, cuotas de GCP; ResourceQuota/LimitRange en Kubernetes). 2. En clústeres compartidos (EKS/AKS/GKE) aísle por namespace con RBAC, NetworkPolicies, Pod Security y nodos dedicados por cliente si manejan datos de tarjeta. 3. Aplique políticas que limiten a cada cliente a sus recursos etiquetados. 4. Revise periódicamente permisos y consumo. 5. Evidencia para el QSA: configuración de privilegios por cliente, cuotas y políticas de aislamiento.", "descripcion_corta_en": "Each customer can only access resources allocated to it", "descripcion_larga_en": "Requirement for multi-tenant service providers: controls must be implemented so that each customer can only access resources allocated to it, preventing intentional or inadvertent impact on resources allocated to other customers.", "remediacion_en": "1. Allocate compute, storage, and network resources per customer (dedicated accounts/subscriptions/projects or namespaces) with quotas and limits (Service Quotas, Azure quotas, GCP quotas; Kubernetes ResourceQuota/LimitRange). 2. In shared clusters (EKS/AKS/GKE) isolate by namespace with RBAC, NetworkPolicies, Pod Security, and dedicated nodes per customer if they handle card data. 3. Apply policies limiting each customer to its tagged resources. 4. Periodically review permissions and consumption. 5. QSA evidence: per-customer privilege configuration, quotas, and isolation policies.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 341, "pagina_pdf_es": 355 }, "kyber_cobertura": { "tipo": "escaneable_directo", "automatizacion": "media", "checks_aws": [ "Clústeres EKS multi-tenant: namespaces de clientes sin NetworkPolicy de denegación por defecto o sin ResourceQuota (falla si existen)", "Políticas IAM de clientes sin condición de etiqueta/recurso que limite a sus recursos asignados (falla si existen)", "Recursos de un cliente accesibles desde la red de otro cliente (security groups que referencian CIDR de otros inquilinos) (falla si existen)" ], "checks_azure": [ "Clústeres AKS multi-tenant sin políticas de red (Azure/Calico) o sin cuotas por namespace (falla si existen)", "Asignaciones RBAC de clientes con alcance a nivel de suscripción compartida en lugar de su grupo de recursos (falla si existen)" ], "checks_gcp": [ "Clústeres GKE multi-tenant sin aplicación de NetworkPolicy o sin ResourceQuota por namespace (falla si existen)", "Reglas de firewall que permiten tráfico entre rangos de distintos inquilinos (falla si existen)" ], "evidencia": "Kyber evalúa aislamiento de red, RBAC y cuotas por inquilino en cuentas y clústeres compartidos; el cliente documenta la asignación de recursos por cliente.", "evidencia_en": "Kyber evaluates network isolation, RBAC, and per-tenant quotas in shared accounts and clusters; the customer documents resource allocation per customer.", "limitaciones": "No detecta impactos de rendimiento entre inquilinos ni aislamiento a nivel de aplicación.", "limitaciones_en": "Does not detect cross-tenant performance impact or application-level isolation.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.3", "8.6", "8.22" ], "soc2_tsc": [ "CC6.1" ], "cis_controls_v8": [ "3.3", "12.2" ] } }, { "id": 211, "numero_regla": "A1.1.4", "requisito": "A1", "seccion": "A1.1", "categoria": "Anexo A1: requisitos adicionales para proveedores de servicios multiusuario", "categoria_en": "Appendix A1: Additional PCI DSS Requirements for Multi-Tenant Service Providers", "seccion_titulo": "Proveedores multiusuario protegen y separan los entornos de sus clientes", "seccion_titulo_en": "Multi-tenant service providers protect and separate customer environments", "descripcion_corta": "Prueba de penetración semestral de la separación lógica entre entornos de clientes", "descripcion_larga": "Requisito para proveedores de servicios multi-tenant: la eficacia de los controles de separación lógica entre entornos de clientes debe confirmarse al menos una vez cada seis meses mediante pruebas de penetración. Esta prueba es adicional a las pruebas de segmentación del Requisito 11.4.6.", "remediacion": "1. Cree entornos temporales de prueba que simulen inquilinos (mock-ups) en cuentas/suscripciones/proyectos con la misma configuración que los clientes reales. 2. Haga que un probador calificado e independiente intente: acceder de un entorno de prueba a otro (red, IAM, almacenamiento, llaves, metadatos de contenedores) y acceder a un entorno de prueba desde Internet. 3. Ejecute la prueba cada seis meses y tras cambios en la arquitectura de tenencia. 4. Remedie y reteste los hallazgos. 5. Evidencia para el QSA: reportes semestrales de pruebas de separación entre clientes con alcance y resultados.", "descripcion_corta_en": "Semi-annual penetration testing of logical separation between customer environments", "descripcion_larga_en": "Requirement for multi-tenant service providers: the effectiveness of logical separation controls between customer environments must be confirmed at least once every six months through penetration testing. This testing is in addition to the segmentation testing of Requirement 11.4.6.", "remediacion_en": "1. Create temporary test environments that simulate tenants (mock-ups) in accounts/subscriptions/projects configured like real customers. 2. Have a qualified, independent tester attempt to: reach one test environment from another (network, IAM, storage, keys, container metadata) and reach a test environment from the Internet. 3. Run the test every six months and after changes to the tenancy architecture. 4. Remediate and retest findings. 5. QSA evidence: semi-annual customer-separation test reports with scope and results.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 342, "pagina_pdf_es": 356 }, "kyber_cobertura": { "tipo": "servicio", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Reportes semestrales de pruebas de penetración de separación entre inquilinos; Kyber puede aportar el inventario de controles de aislamiento como insumo de alcance.", "evidencia_en": "Semi-annual tenant-separation penetration test reports; Kyber can provide the isolation-control inventory as scoping input.", "limitaciones": "Requiere un servicio humano de pruebas de penetración.", "limitaciones_en": "Requires a human penetration testing service.", "responsabilidad_compartida": "compartida", "control_type": "process", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "8.22", "8.8" ], "soc2_tsc": [ "CC4.1" ], "cis_controls_v8": [ "18.4" ] } }, { "id": 212, "numero_regla": "A1.2.1", "requisito": "A1", "seccion": "A1.2", "categoria": "Anexo A1: requisitos adicionales para proveedores de servicios multiusuario", "categoria_en": "Appendix A1: Additional PCI DSS Requirements for Multi-Tenant Service Providers", "seccion_titulo": "Registro y respuesta a incidentes por cliente en proveedores multiusuario", "seccion_titulo_en": "Per-customer logging and incident response for multi-tenant providers", "descripcion_corta": "Capacidad de registros de auditoría por cliente consistente con el Requisito 10", "descripcion_larga": "Requisito para proveedores de servicios multi-tenant: debe habilitarse la capacidad de registros de auditoría para el entorno de cada cliente de forma consistente con el Requisito 10, de modo que: se registren las aplicaciones de terceros comunes; los registros estén activos por defecto; solo el cliente propietario pueda revisarlos; su ubicación se comunique claramente al cliente; y los datos y su disponibilidad cumplan con el Requisito 10.", "remediacion": "1. En cada cuenta/suscripción/proyecto de cliente habilite por defecto mediante plantillas de aprovisionamiento: CloudTrail (organización o por cuenta) con validación de integridad, VPC Flow Logs, registros de servicios administrados; Azure Activity Log y diagnósticos hacia un Log Analytics por cliente; Cloud Audit Logs (incluidos Data Access) y sinks por proyecto en GCP. 2. Entregue los registros en almacenamiento separado por cliente (bucket/workspace/proyecto de registros) con acceso restringido al cliente propietario. 3. Configure retención de al menos 12 meses con 3 meses disponibles de inmediato. 4. Documente y comunique al cliente la ubicación y forma de acceso a sus registros. 5. Evidencia para el QSA: plantillas de aprovisionamiento, políticas de acceso a registros y configuración de retención.", "descripcion_corta_en": "Per-customer audit log capability consistent with Requirement 10", "descripcion_larga_en": "Requirement for multi-tenant service providers: audit log capability must be enabled for each customer environment consistent with Requirement 10, so that: common third-party applications are logged; logs are active by default; only the owning customer can review them; log locations are clearly communicated to the customer; and log data and availability meet Requirement 10.", "remediacion_en": "1. In every customer account/subscription/project, enable by default via provisioning templates: CloudTrail (organization or per account) with integrity validation, VPC Flow Logs, managed service logs; Azure Activity Log and diagnostics into a per-customer Log Analytics workspace; Cloud Audit Logs (including Data Access) and per-project sinks in GCP. 2. Deliver logs into per-customer storage (logging bucket/workspace/project) with access restricted to the owning customer. 3. Configure retention of at least 12 months with 3 months immediately available. 4. Document and communicate to each customer the location and access method for its logs. 5. QSA evidence: provisioning templates, log access policies, and retention configuration.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "high", "referencia_documento": { "pagina_pdf_en": 343, "pagina_pdf_es": 357 }, "kyber_cobertura": { "tipo": "retencion_medible", "automatizacion": "alta", "checks_aws": [ "CloudTrail multi-región habilitado en cada cuenta de cliente con validación de integridad de archivos de log [CloudTrail.1] [CloudTrail.4]", "VPC Flow Logs habilitados en las VPC de cada cliente [EC2.6]", "Bucket S3 de registros por cliente con retención (lifecycle/Object Lock) ≥ 365 días (falla si es menor)", "Política de bucket de registros que permite lectura a principales de otros clientes (falla si existe)" ], "checks_azure": [ "Configuración de diagnóstico del Activity Log de cada suscripción de cliente hacia su workspace de Log Analytics", "Workspace de Log Analytics por cliente con retención total ≥ 365 días (falla si es menor)", "Asignaciones RBAC sobre el workspace de un cliente para identidades de otros clientes (falla si existen)" ], "checks_gcp": [ "Cloud Audit Logs Data Access habilitados en los proyectos de clientes", "Buckets de registros (_Default o personalizados) por cliente con retentionDays ≥ 365 (falla si es menor)", "Permisos de lectura de registros de un proyecto de cliente concedidos a principales de otros clientes (falla si existen)" ], "evidencia": "Kyber mide por cliente que los registros estén activos, aislados y con retención suficiente; el proveedor aporta la comunicación a clientes sobre la ubicación de sus registros.", "evidencia_en": "Kyber measures per customer that logs are active, isolated, and retained long enough; the provider supplies the customer communication about log locations.", "limitaciones": "Kyber no verifica el registro dentro de aplicaciones de terceros instaladas en las cargas de trabajo ni la comunicación a clientes.", "limitaciones_en": "Kyber does not verify logging inside third-party applications installed on workloads or the communication to customers.", "responsabilidad_compartida": "compartida", "control_type": "technical", "automatable": true }, "mapeo_frameworks": { "iso27001_2022": [ "8.15" ], "soc2_tsc": [ "CC7.2" ], "cis_controls_v8": [ "8.2", "8.10" ] } }, { "id": 213, "numero_regla": "A1.2.2", "requisito": "A1", "seccion": "A1.2", "categoria": "Anexo A1: requisitos adicionales para proveedores de servicios multiusuario", "categoria_en": "Appendix A1: Additional PCI DSS Requirements for Multi-Tenant Service Providers", "seccion_titulo": "Registro y respuesta a incidentes por cliente en proveedores multiusuario", "seccion_titulo_en": "Per-customer logging and incident response for multi-tenant providers", "descripcion_corta": "Procesos para facilitar investigaciones forenses oportunas para cualquier cliente", "descripcion_larga": "Requisito para proveedores de servicios multi-tenant: deben implementarse procesos o mecanismos que apoyen y faciliten investigaciones forenses oportunas ante un incidente de seguridad sospechado o confirmado de cualquier cliente.", "remediacion": "1. Documente un procedimiento forense por cliente: preservación de evidencia (snapshots de EBS/discos administrados/Persistent Disk, captura de memoria, copias de registros) con cadena de custodia. 2. Prepare cuentas/suscripciones/proyectos forenses aislados y roles predefinidos para investigadores con acceso solo al cliente afectado. 3. Automatice el aislamiento y la captura (p. ej., AWS Systems Manager Automation/Lambda, Azure Logic Apps, Cloud Functions) y use Amazon Detective, Microsoft Sentinel o Chronicle para análisis. 4. Defina SLA de atención a solicitudes de investigadores forenses (PFI) del cliente. 5. Evidencia para el QSA: procedimientos documentados, runbooks y registros de ejercicios o casos atendidos.", "descripcion_corta_en": "Processes to support prompt forensic investigations for any customer", "descripcion_larga_en": "Requirement for multi-tenant service providers: processes or mechanisms must be implemented to support and facilitate prompt forensic investigations in the event of a suspected or confirmed security incident for any customer.", "remediacion_en": "1. Document a per-customer forensic procedure: evidence preservation (EBS/managed disk/Persistent Disk snapshots, memory capture, log copies) with chain of custody. 2. Prepare isolated forensic accounts/subscriptions/projects and predefined roles for investigators with access only to the affected customer. 3. Automate isolation and capture (e.g., AWS Systems Manager Automation/Lambda, Azure Logic Apps, Cloud Functions) and use Amazon Detective, Microsoft Sentinel, or Chronicle for analysis. 4. Define SLAs for handling requests from the customer's forensic investigators (PFI). 5. QSA evidence: documented procedures, runbooks, and records of exercises or handled cases.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": false, "obligatorio_desde": "2024-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 344, "pagina_pdf_es": 358 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "baja", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Procedimiento forense documentado, runbooks de captura de evidencia y registros de ejercicios o casos; Kyber puede verificar la existencia de cuentas forenses y la capacidad de snapshots.", "evidencia_en": "Documented forensic procedure, evidence-capture runbooks, and exercise or case records; Kyber can verify the existence of forensic accounts and snapshot capability.", "limitaciones": "La oportunidad y calidad de la respuesta forense no es verificable por escaneo.", "limitaciones_en": "Timeliness and quality of the forensic response are not verifiable by scanning.", "responsabilidad_compartida": "compartida", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "5.28", "5.26" ], "soc2_tsc": [ "CC7.4" ], "cis_controls_v8": [ "17.4" ] } }, { "id": 214, "numero_regla": "A1.2.3", "requisito": "A1", "seccion": "A1.2", "categoria": "Anexo A1: requisitos adicionales para proveedores de servicios multiusuario", "categoria_en": "Appendix A1: Additional PCI DSS Requirements for Multi-Tenant Service Providers", "seccion_titulo": "Registro y respuesta a incidentes por cliente en proveedores multiusuario", "seccion_titulo_en": "Per-customer logging and incident response for multi-tenant providers", "descripcion_corta": "Mecanismos para que los clientes reporten incidentes y vulnerabilidades y su atención", "descripcion_larga": "Requisito para proveedores de servicios multi-tenant: deben implementarse procesos o mecanismos para reportar y atender incidentes de seguridad y vulnerabilidades sospechados o confirmados, de modo que los clientes puedan reportarlos de forma segura al proveedor, y que el proveedor los atienda y remedie conforme al Requisito 6.3.1.", "remediacion": "1. Publique un canal seguro de reporte para clientes (portal autenticado, correo con cifrado o formulario HTTPS, y un security.txt) con acuse de recibo. 2. Integre los reportes al proceso de gestión de incidentes y vulnerabilidades, clasificándolos según 6.3.1 con SLA de remediación. 3. Notifique a los clientes afectados cuando corresponda. 4. Registre y dé seguimiento a cada reporte hasta su cierre. 5. Evidencia para el QSA: procedimiento documentado, canal publicado y registro de reportes atendidos.", "descripcion_corta_en": "Mechanisms for customers to report incidents and vulnerabilities and their handling", "descripcion_larga_en": "Requirement for multi-tenant service providers: processes or mechanisms must be implemented for reporting and addressing suspected or confirmed security incidents and vulnerabilities, so that customers can securely report them to the provider and the provider addresses and remediates them according to Requirement 6.3.1.", "remediacion_en": "1. Publish a secure reporting channel for customers (authenticated portal, encrypted email, or HTTPS form, plus a security.txt) with acknowledgment of receipt. 2. Feed reports into the incident and vulnerability management process, ranking them per 6.3.1 with remediation SLAs. 3. Notify affected customers where appropriate. 4. Log and track each report to closure. 5. QSA evidence: documented procedure, published channel, and log of handled reports.", "aplica_a": "solo_proveedores_de_servicio", "nuevo_en_v4": true, "obligatorio_desde": "2025-03-31", "severidad": "low", "referencia_documento": { "pagina_pdf_en": 345, "pagina_pdf_es": 359 }, "kyber_cobertura": { "tipo": "documental", "automatizacion": "n/a", "checks_aws": [], "checks_azure": [], "checks_gcp": [], "evidencia": "Procedimiento de reporte y atención, canal seguro publicado y registro de reportes de clientes atendidos.", "evidencia_en": "Reporting and handling procedure, published secure channel, and log of handled customer reports.", "limitaciones": "No verificable por escaneo de nube.", "limitaciones_en": "Not verifiable by cloud scanning.", "responsabilidad_compartida": "compartida", "control_type": "documentary", "automatable": false }, "mapeo_frameworks": { "iso27001_2022": [ "6.8", "5.24", "8.8" ], "soc2_tsc": [ "CC2.3", "CC7.3" ], "cis_controls_v8": [ "17.3", "7.2" ] } } ] }