PCI DSS v4.0.1 (requisitos 6 y 11)
Attestkeep vincula lo que el admission control y el escaneo de images de su cluster registraron en un periodo con 13 requisitos (fuente: PCI Security Standards Council, Payment Card Industry Data Security Standard, versión 4.0.1, junio de 2024). De ellos, 8 se evalúan con esos registros; 5 se marcan fuera de alcance, cada uno con el motivo.
8 requisitos a los que responde un cluster.
Referencias y títulos tal como los imprime el informe, es decir, en inglés. Abra un requisito para leer lo que pide, expresado de forma próxima al texto del propio instrumento.
PCI DSS v4.0.1
PCI Security Standards Council, Payment Card Industry Data Security Standard, versión 4.0.1, junio de 2024
Requisitos 6.3 y 6.5 (gestión de vulnerabilidades y control de cambios), requisito 10.2 (registros de auditoría) y requisito 11.3 (escaneos internos de vulnerabilidades)
| Referencia | Requisito | Secciones del informe |
|---|---|---|
| Requirement 6.3.1 | Security vulnerabilities are identified and risk-rankedLas nuevas vulnerabilidades de seguridad se identifican con fuentes de información reconocidas en el sector, incluidas las alertas de los equipos de respuesta a emergencias informáticas nacionales e internacionales, y reciben una clasificación de riesgo que identifica al menos todas las vulnerabilidades consideradas de alto riesgo o críticas para el entorno; se cubren las vulnerabilidades del software desarrollado a medida y del software de terceros, como sistemas operativos y bases de datos. | CoverageClusterAdmission decisionsOutcomesDeployment contextControl statement |
| Requirement 6.3.2 | Inventory of bespoke, custom and third-party software componentsSe mantiene un inventario del software desarrollado a medida y de los componentes de software de terceros que incorpora, para facilitar la gestión de vulnerabilidades y parches. | Supply chainCoverage |
| Requirement 6.3.3 | System components are protected from known vulnerabilities by patchingTodos los componentes del sistema se protegen de las vulnerabilidades conocidas instalando los parches de seguridad aplicables: los de vulnerabilidades críticas, identificadas según la clasificación del requisito 6.3.1, en el mes siguiente a su publicación, y todos los demás en un plazo adecuado fijado por la evaluación de la criticidad del riesgo que haga la entidad. | Control statementCoverageAdmission decisionsOutcomes |
| Requirement 6.5.1 | Changes to system components follow change control proceduresLos cambios en todos los componentes del sistema del entorno de producción siguen procedimientos establecidos: motivo y descripción del cambio, impacto de seguridad documentado, aprobación documentada por personas autorizadas, pruebas que verifiquen que el cambio no perjudica la seguridad del sistema, pruebas de las actualizaciones del software a medida frente al requisito 6.2.4 antes de pasar a producción, y procedimientos para gestionar fallos y volver a un estado seguro. | Admission decisionsEvidence chain |
| Requirement 10.2.2 | What each audit log entry recordsLos registros de auditoría recogen, para cada evento auditable, la identificación del usuario, el tipo de evento, la fecha y la hora, la indicación de éxito o fallo, el origen del evento y la identidad o el nombre de los datos, componentes del sistema, recursos o servicios afectados. | Evidence chain |
| Requirement 11.3.1 | Internal vulnerability scans at least once every three monthsLos escaneos internos de vulnerabilidades se realizan al menos una vez cada tres meses, las vulnerabilidades de alto riesgo y críticas se resuelven, nuevos escaneos confirman que se han resuelto, la herramienta de escaneo se mantiene al día con la información de vulnerabilidades y los escaneos los realiza personal cualificado con independencia organizativa respecto de quien los ejecuta. | CoverageAdmission decisionsOutcomesControl statementIssues |
| Requirement 11.3.1.1 | Vulnerabilities not ranked high-risk or criticalTodas las demás vulnerabilidades aplicables se gestionan según el riesgo definido en el análisis de riesgos específico de la entidad, con nuevos escaneos cuando haga falta. | Triage decisionsCoverageDeployment context |
| Requirement 11.3.1.2 | Internal scans are performed via authenticated scanningLos escaneos internos de vulnerabilidades son autenticados, con privilegios suficientes en los sistemas que aceptan credenciales; los que no pueden aceptarlas se documentan, y cualquier cuenta usada para el escaneo autenticado que también permita iniciar sesión de forma interactiva se gestiona según el requisito 8.2.2. | Coverage |
5 requisitos fuera de alcance, y por qué
| Referencia | Requisito y motivo |
|---|---|
| Requirement 6.4.2 | Automated protection for public-facing web applications Este control decide qué image puede ejecutarse; no ve nada del tráfico al que la aplicación responde después, que es por donde llega un ataque web. |
| Requirement 6.4.3 | Payment page scripts are authorised, integrity-assured and inventoried Los scripts que una página de pago sirve al navegador son contenido que la aplicación genera durante la ejecución, por debajo de la image que este control admite e invisible para él. |
| Requirement 10.2.1 | Audit logs are enabled and active El registro se activa componente a componente en el entorno de la entidad; este documento acredita el registro que este control lleva de sus propias decisiones, del que informa 10.2.2 más abajo, y no puede decir nada del resto. |
| Requirement 11.3.2 | External vulnerability scans by an Approved Scanning Vendor Un ASV escanea la superficie de ataque externa de la entidad desde fuera e informa según la ASV Program Guide; nada de ese trabajo es observable desde dentro de un cluster. |
| Requirement 12.3.1 | Targeted risk analysis for a frequency the entity sets El análisis que fija la frecuencia de 11.3.1.1 es un documento que la entidad redacta, aprueba y revisa; este control funciona con la frecuencia que resulte de él y no puede sustituirlo. |
Evidencia a partir de registros que el cluster ya guarda.
Nada se rellena a mano. La respuesta de cada requisito lleva un estado (cumplido, parcial, carencia o fuera de alcance), una nota con las cifras del propio periodo y las secciones del informe de donde salen esas cifras.
En qué se apoya el mapeo
Cada requisito evaluado se responde con una o varias de estas afirmaciones sobre los registros del periodo. La misma afirmación responde a la misma pregunta en todos los frameworks, así que dos informes de un mismo periodo no pueden discrepar.
- Cada image del inventario tiene un registro de escaneo4 requisitos
- Se rechazan las images con hallazgos graves3 requisitos
- Se registra cada decisión y cada acción administrativa2 requisitos
- Los umbrales de vulnerabilidad son más estrictos donde el workload está expuesto o tiene privilegios2 requisitos
- La admission rechaza los workloads que no cumplen1 requisito
- Cada cambio de image se registra junto a la policy que lo regía1 requisito
- Los riesgos aceptados tienen nombre, justificación y caducidad1 requisito
- Los hallazgos se cotejan con un catálogo nacional de vulnerabilidades explotadas1 requisito
- Los hallazgos críticos tienen un plazo de corrección de un mes como máximo1 requisito
- Hay un plazo de corrección declarado para cada severidad1 requisito
- Se guarda un SBOM de las images en servicio1 requisito
- Las images se escanean mediante un pull autenticado con las credenciales del propio workload1 requisito
Qué contiene el informe.
Todos los paquetes llevan las mismas secciones, sea cual sea el framework. Las marcadas son las que citan las respuestas para PCI DSS, con el número de requisitos que cita cada una.
- Organisation
- Framework mapping
- Cluster1
- Control statement3
- Coverage6
- Vulnerability findings
- Outcomes3
- Admission decisions4
- Supply chain1
- Triage decisions1
- Break-glass events
- Availability
- Evidence chain2
- Deployment context2
- Issues1
- Ledger
- Population
- Runtime events
- Producer statements (VEX)
El párrafo de alcance, tal como lo formula el informe.
This document reports what one Kubernetes cluster's admission control and image scanning recorded during the period, mapped onto PCI DSS v4.0.1. It is not a Report on Compliance and not an Attestation of Compliance: those are issued by a Qualified Security Assessor or a qualified internal resource against the entity's whole cardholder data environment, and only the entity defines what is in that environment. Nothing here establishes that this cluster is in scope for PCI DSS, or that it is out of it. What the period's records support is the vulnerability management clauses of Requirement 6 and the internal scanning clauses of Requirement 11 for the images this cluster admitted, together with the audit log clauses of 10.2 for the decisions it took. The document records the version of the CISA Known Exploited Vulnerabilities catalogue the period's decisions were taken against, which is one of the industry-recognised sources Requirement 6.3.1 asks for; the mapping below reads the scan and admission records rather than that catalogue directly. Account data at rest and in transit, the web application and payment page clauses of 6.4, the Approved Scanning Vendor scans of 11.3.2 and the organisational programme of Requirement 12 are outside what a cluster observes and are marked as such.
Sobre PCI DSS
¿Es esto una certificación según PCI DSS?
No. El paquete es evidencia generada a partir de los propios registros de su cluster. No es una certificación, y ningún auditor está obligado a aceptarlo. El párrafo de alcance de esta página es el mismo que lleva el informe.
¿Por qué 5 de los requisitos están fuera de alcance?
Preguntan por cosas que los registros de admission y escaneo de un cluster no pueden mostrar. Se incluyen con el motivo en lugar de omitirse, para que quien lea el informe vea que la exclusión es deliberada.
¿Qué plan incluye PCI DSS?
Todos los planes pueden generar informes para este framework. Community y Team incluyen 1 framework a elegir; Business, 3; Enterprise, todos. Los precios están en la página de precios.
¿Cómo comprueba un auditor el paquete?
En un navegador, en attestkeep.com/verify.html, donde no se sube nada, o con el breve script del sitio de documentación. Ninguno de los dos nos necesita. La página Para auditores tiene los detalles.
Instálelo usted mismo.
Cree una cuenta, confirme su correo con el código que le enviamos, obtenga la clave Community gratuita en la página Licences e instale con Helm.
Crear una cuenta