Mapa de controles · v4.0

PCI DSS

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

11 de 26 controles de PCI DSS que el código puede evidenciar, con v1.4.0, más 1 de apoyo

Evidencia de código hoy para datos de tarjeta almacenados y en tránsito, secretos, acceso y código seguro; aprobación de cambios en v1.4.0.

Activo10
Próximamente en v1.4.01
De apoyo1
Planificado15
Su organización36

10 con evidencia de código hoyEvidencia parcial, comprobada en cada pull request.
1 más en v1.4.0Evidencia de proceso a partir de fusiones, aprobaciones y cambios de reglas.
36 quedan en su organizaciónEnumerados completos más abajo, para que nada quede implícito.

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.

Hoy el blueprint de PCI DSS aporta evidencia de código para diez requisitos, entre ellos el cifrado de datos almacenados, el cifrado en tránsito y los secretos de cuentas de servicio. Desde v1.4.0, cada cambio fusionado lleva su aprobación como registro sellado, y la revisión previa a la fusión refuerza la evidencia de código seguro.

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.

Activo10

Evidencia de código hoy, sellada en cada pull request. Siempre parcial: el control también exige cosas fuera del código. Evidencia de código hoy: las reglas del blueprint PCI DSS comprueban parte de esto en cada pull request.

Req.1.3
Límites al tráfico entrante
Req.1 Reglas de perímetro de red
Req.3.3
Retención de secretos de acceso
Req.3 Protección de datos almacenados
Req.3.5
Cifrado de datos almacenados
Req.3 Protección de datos almacenados
Req.3.6
Protección de claves
Req.3 Protección de datos almacenados
Req.4.2
Cifrado en tránsito
Req.4 Cifrado en tránsito
Req.6.2
Hábitos de código seguro
Req.6 Trabajo de software seguro
Reforzado en v1.4.0: la revisión previa a la fusión se sella por cambio.
Req.6.3
Análisis de vulnerabilidades
Req.6 Trabajo de software seguro
Req.7.2
Derechos de acceso por rol
Req.7 Límites de acceso
Req.7.3
Límites de acceso a sistemas
Req.7 Límites de acceso
Req.8.6
Secretos de cuentas de servicio
Req.8 Identidad de usuario

Próximamente en v1.4.01

Evidencia de proceso: pull requests fusionados, aprobaciones, checks obligatorios, protección de ramas, rulesets y bypasses, sellada por cada cambio.

Req.6.5
Aprobación de cambios
Req.6 Trabajo de software seguro
Evidencia de proceso: cada pull request fusionado 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.

De apoyo1

Toevan registra evidencia relacionada, hoy o en v1.4.0, pero la obligación es organizativa, así que nunca cuenta como cubierta.

Req.12.10
Plan de respuesta a incidentes
Req.12 Programa de gobernanza
Evidencia de apoyo hoy: una regla registra evidencia relacionada con esta obligación. La obligación en sí es un proceso operativo.

Planificado15

Se puede evidenciar desde el código o GitHub. La regla o el mapeo aún no están construidos.

Req.1.2
Configuración de red
Req.1 Reglas de perímetro de red
Req.1.4
Bordes de red de confianza
Req.1 Reglas de perímetro de red
Req.2.2
Ajustes de bastionado del sistema
Req.2 Ajustes de sistema bastionados
Req.3.2
Límites de conservación de datos
Req.3 Protección de datos almacenados
Req.3.4
Enmascaramiento de números de tarjeta
Req.3 Protección de datos almacenados
Req.6.4
Defensas contra ataques web
Req.6 Trabajo de software seguro
Req.8.2
Ciclo de vida de cuentas
Req.8 Identidad de usuario
Req.8.3
Autenticación robusta
Req.8 Identidad de usuario
Req.8.4
Uso del segundo factor
Req.8 Identidad de usuario
Req.8.5
Ajustes del segundo factor
Req.8 Identidad de usuario
Req.10.2
Contenido de logs de auditoría
Req.10 Registro de auditoría
Req.10.3
Protección de logs contra manipulación
Req.10 Registro de auditoría
Req.10.5
Conservación de logs
Req.10 Registro de auditoría
Req.11.3
Análisis recurrentes
Req.11 Pruebas de seguridad
Req.11.6
Integridad de páginas de pago
Req.11 Pruebas de seguridad

Su organización36

Política, personas, seguridad física, contratos, trámites regulatorios, operaciones o auditoría externa. Su organización aporta la evidencia.

Mostrar los 36 controles

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

Cómo usarlo en una auditoría

Tome la población de los registros de cambio (desde v1.4.0)
Cada fusión en una rama protegida y cada push directo del 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 para v1.4.1.
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 verifique su firma y su lugar en la cadena sin conexión.
$ toevan audit verify --path evidence-clone --pub-key toevan.pub

Cómo se obtuvo cada dato

Cada dato de un registro y de un informe lleva una de seis etiquetas, para que su auditor sepa hasta qué punto puede fiarse.

Recalculado: Toevan lo calculó a partir del propio código o del historial de git.; Repítalo con las mismas entradas y obtenga el mismo resultado.
Informado + sellado: GitHub lo informó; Toevan lo capturó en el evento y lo firmó.; Fíese de ello tanto como se fía de GitHub. Cualquier cambio posterior es detectable.
Declarado + sellado: La organización lo declaró, como un cambio en lo que se comprueba; Toevan firmó la declaración y su historial.; Vea quién declaró qué, cuándo, y cada cambio posterior.
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.; Trátelo como una declaración de Toevan y pida a la organización la aprobación que hay detrás.
Consumido: Tomado del registro firmado de otro sistema, como la procedencia de una compilación, y enlazado por commit o digest. Planificado.; Compruebe el registro original de forma independiente.
No capturado: No había una fuente fiable. Toevan no lo infiere.; Obténgalo de la organización por otros medios.

Véalo en un informe

El informe de muestra de evidencia de cambios muestra la evidencia tal como la recibe su auditor, con cada dato rotulado.

Abrir el informe de muestra

Ponga a prueba el mapeo en una auditoría real.

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