Mapa de controles · v4.0

PCI DSS

Evidencia de código para datos de tarjeta almacenados y en tránsito, secretos, acceso y código seguro, y aprobación de cambios desde cada fusión.

Reserve un piloto de auditoría Ver un informe de muestra

PCI DSS · v4.026 requisitos en el alcance · según el mapeo de v1.4.1

Código 9
Proceso 1
Planificado 16

Evidencia de código

9requisitos comprobados en cada pull request

Activo (proceso)

1de fusiones, aprobaciones, cambios de reglas y despliegues y releases registrados por GitHub

Planificado

16se puede evidenciar desde el código o GitHub; aún no construido

Requisitos de nivel organizativo

Políticas, personas, proveedores, seguridad física y similares, enumerados más abajo.Gestionados por los procesos de su organización

Los evaluadores comprueban el software seguro y el control de cambios a partir de tickets de cambio, registros de revisión de código y resultados de análisis.

El blueprint de PCI DSS aporta evidencia de código para requisitos como el cifrado de datos almacenados, el cifrado en tránsito y los secretos de cuentas de servicio. Cada cambio fusionado lleva su aprobación como registro sellado.

Toevan aporta evidencia para controles; nunca los certifica ni afirma que un marco esté cubierto. Si la evidencia es suficiente lo juzga su auditor. Los controles se muestran por id con los nombres cortos propios de Toevan; los títulos oficiales y el texto de los requisitos pertenecen al editor del marco.

Evidencia de código9

Sellada en cada pull request. Siempre parcial: el control también exige cosas fuera del código. Las reglas del blueprint PCI DSS comprueban parte de cada uno en cada pull request.

Req.1.3Límites al tráfico entranteReq.1 Reglas de perímetro de red
Req.3.3Retención de secretos de accesoReq.3 Protección de datos almacenados
Req.3.5Cifrado de datos almacenadosReq.3 Protección de datos almacenados
Req.3.6Protección de clavesReq.3 Protección de datos almacenados
Req.4.2Cifrado en tránsitoReq.4 Cifrado en tránsito
Req.6.3Análisis de vulnerabilidadesReq.6 Trabajo de software seguro
Req.7.2Derechos de acceso por rolReq.7 Límites de acceso
Req.7.3Límites de acceso a sistemasReq.7 Límites de acceso
Req.8.6Secretos de cuentas de servicioReq.8 Identidad de usuario

Activo (proceso)1

Pull requests fusionados, aprobaciones, checks obligatorios, protección de ramas, rulesets y bypasses, y despliegues y releases registrados por GitHub, cada uno sellado.

Req.6.5Aprobación de cambiosReq.6 Trabajo de software seguroEvidencia de proceso: cada pull request fusionado en la rama por defecto se sella como un registro de cambio con sus aprobaciones sobre el commit final, los checks obligatorios al fusionar, quién lo fusionó, sus firmas y los veredictos de código que llevaba.

Registro de cambio rec_5b81d4e

datos de ejemplo

Pull request payments-api #1921 · Add tenant check to refund handlerInformado + sellado

Aprobaciones 9d07…e3a4, c58f…71d0 · ambas sobre el commit final e81b2d0Informado + sellado

Independiente del autor Sí, por id de cuenta de GitHubRecalculado

Checks obligatorios ci/test ✓ · ci/lint ✓ · toevan/gate ✓Informado + sellado

Reglas vigentes main-protection: 2 aprobaciones, checks obligatorios, commits firmadosInformado + sellado

Planificado16

Se puede evidenciar desde el código o GitHub. Todavía ninguna regla los comprueba; cada uno está planificado y ninguno cuenta hoy como evidencia.

Req.1.2Configuración de redReq.1 Reglas de perímetro de red
Req.1.4Bordes de red de confianzaReq.1 Reglas de perímetro de red
Req.2.2Ajustes de bastionado del sistemaReq.2 Ajustes de sistema bastionados
Req.3.2Límites de conservación de datosReq.3 Protección de datos almacenados
Req.3.4Enmascaramiento de números de tarjetaReq.3 Protección de datos almacenados
Req.6.2Hábitos de código seguroReq.6 Trabajo de software seguro
Req.6.4Defensas contra ataques webReq.6 Trabajo de software seguro
Req.8.2Ciclo de vida de cuentasReq.8 Identidad de usuario
Req.8.3Autenticación robustaReq.8 Identidad de usuario
Req.8.4Uso del segundo factorReq.8 Identidad de usuario
Req.8.5Ajustes del segundo factorReq.8 Identidad de usuario
Req.10.2Contenido de logs de auditoríaReq.10 Registro de auditoría
Req.10.3Protección de logs contra manipulaciónReq.10 Registro de auditoría
Req.10.5Conservación de logsReq.10 Registro de auditoría
Req.11.3Análisis recurrentesReq.11 Pruebas de seguridad
Req.11.6Integridad de páginas de pagoReq.11 Pruebas de seguridad

Requisitos de nivel organizativo

Los controles de nivel organizativo (políticas, personas, proveedores, seguridad física y similares) siguen en manos del propio proceso de su organización; Toevan no se ocupa de ellos.

Mostrar la lista

Req.1 Reglas de perímetro de red

Req.1.1Registro de la política de reduna política de la organización

Req.1.5Política de puentes en endpointsuna política de la organización

Req.2 Ajustes de sistema bastionados

Req.2.1Registro de la política de bastionadouna política de la organización

Req.2.3Revisión de redes inalámbricasun proceso operativo

Req.3 Protección de datos almacenados

Req.3.1Política de protección de datosuna política de la organización

Req.3.7Proceso del ciclo de vida de clavesun proceso operativo

Req.4 Cifrado en tránsito

Req.4.1Registro de la política de tránsitouna política de la organización

Req.5 Defensa frente a malware

Req.5.1Registro de la política contra malwareuna política de la organización

Req.5.2Defensa de endpoints contra malwareun proceso operativo

Req.5.3Vigilancia de antimalware al díaun proceso operativo

Req.5.4Defensas contra phishingun proceso operativo

Req.6 Trabajo de software seguro

Req.6.1Registro de la política de desarrollouna política de la organización

Req.7 Límites de acceso

Req.7.1Registro de la política de accesouna política de la organización

Req.8 Identidad de usuario

Req.8.1Política de inicio de sesiónuna política de la organización

Req.9 Acceso físico a instalaciones

Req.9.1Registro de la política físicauna política de la organización

Req.9.2Controles de entrada a instalacionesseguridad física

Req.9.3Registros de acceso de visitantesseguridad física

Req.9.4Reglas de manejo de soportesseguridad física

Req.9.5Revisión de manipulación de terminalesseguridad física

Req.10 Registro de auditoría

Req.10.1Registro de la política de logsuna política de la organización

Req.10.4Revisión periódica de logsun proceso operativo

Req.10.6Sincronización de relojesun proceso operativo

Req.10.7Proceso de detección de fallosun proceso operativo

Req.11 Pruebas de seguridad

Req.11.1Registro de la política de pruebasuna política de la organización

Req.11.2Revisión de redes wifi ajenasun proceso operativo

Req.11.4Pruebas de penetraciónuna evaluación externa

Req.11.5Proceso de detección de intrusionesun proceso operativo

Req.12 Programa de gobernanza

Req.12.1Programa de política de seguridaduna política de la organización

Req.12.2Reglas de uso aceptableuna política de la organización

Req.12.3Revisión de riesgos específicauna política de la organización

Req.12.4Supervisión del cumplimientouna política de la organización

Req.12.5Registro de definición del alcanceuna política de la organización

Req.12.6Formación de concienciaciónun asunto de personas y RR. HH.

Req.12.7Selección de personalun asunto de personas y RR. HH.

Req.12.8Contratos con proveedorescontratos y proveedores

Req.12.9Deberes de soporte de proveedorescontratos y proveedores

Req.12.10Plan de respuesta a incidentesun proceso operativo

Cómo usarlo en una auditoría

Tome la población de los registros de cambio
Cada pull request fusionado en la rama por defecto y cada push a una rama protegida que ningún pull request fusionado explique, en el periodo, capturados de GitHub en el momento, es un registro sellado que puede exportar para el muestreo. Puede repetir la población de la rama por defecto a partir del historial de git; las ramas de producción designadas están planificadas.
Lea la evidencia de código del periodo
Cada pull request lleva resultados de código sellados frente a las reglas del blueprint, fijados al commit y a la versión del conjunto de reglas vigente.
Pruebe una muestra
Para cada registro muestreado, compruebe sus resultados y luego verifíquelo sin conexión con la clave publicada, con openssl y la shell: obtenga la evidencia, confirme la clave, compruebe el registro. Para repetir toda la cadena, Toevan facilita el comando toevan a petición; aún no es público.
Los tres pasos, con los comandos exactos

Cómo se obtuvo cada hecho6 etiquetas

Recalculado: Toevan lo calculó a partir del propio código o del historial de git.
Informado + sellado: GitHub lo informó; Toevan lo capturó en el evento y lo firmó.
Declarado + sellado: La organización lo declaró, como un cambio en lo que se comprueba; Toevan firmó la declaración y su historial.
Registro de Toevan, sin sellar: Guardado en la base de datos de Toevan pero no sellado en el libro, como una exención hoy. Ninguna firma lo protege.
Consumido: Tomado de los registros de despliegue y de release de GitHub y enlazado por commit o digest.
No capturado: No había una fuente fiable. Toevan no lo infiere.

Req.6.5Aprobaciones de cambiosHoja de pruebas · datos de ejemplo

Población148 cambios: 146 pull requests fusionados y 2 pushes directos
Recalculado listado desde el historial de git y cotejado con los registros sellados

Muestra25 extraídos por el auditor, cada uno un registro sellado

AprobacionesInformado + sellado de GitHub en la fusión, independientes del autor

ExcepcionesSin PR 2 pushes directos el 19 sepHueco requisito de revisión desactivado durante 29 minutosAmbos constan en el registro.

Firmas25 / 25 ✓ Verified OK

El informe de muestra de evidencia de cambios muestra la evidencia tal como la recibe su auditor, con cada hecho etiquetado.Abrir el informe de muestra

Pruebe el mapeo en una auditoría real.

Traiga un repositorio y una auditoría próxima. Configuraremos el blueprint y guiaremos a su auditor en la verificación.

Reserve un piloto de auditoría Ver un informe de muestra

Un repositorio, un marco
Evidencia desde el primer pull request
Verificable sin una cuenta de Toevan