Fundamentos técnicos para el assessor

Esta guía reúne conceptos técnicos que aparecen como distractores en preguntas ISA. No reemplaza el estándar ni el glosario: organiza lo que un assessor necesita distinguir rápidamente cuando una pregunta mezcla criptografía, redes, monitoreo, POI o flujo de pago.

Cómo usar esta guía

• Lee primero la regla de examen de cada sección y después la tabla comparativa.
• Usa las citas PCI DSS como ancla normativa; usa las referencias NIST/RFC solo para entender tecnología.
• Cuando un término aparezca definido en el estándar, contrástalo con glosario.md.
• Para el repaso final, salta directo a las tablas de comparación y a las reglas mnemotécnicas.

1. Criptografía aplicada en PCI DSS

1.1 Cifrado simétrico vs asimétrico

Regla de examen: el cifrado simétrico protege datos con una clave compartida; el cifrado asimétrico usa un par de claves. PCI DSS no pregunta teoría pura: pregunta si el método protege PAN, transmisión o llaves con criptografía sólida.

Punto	Simétrico	Asimétrico
Claves	Una clave secreta compartida	Par pública/privada
Uso típico	Cifrado masivo de datos, DEK, canales de sesión	Intercambio de llaves, certificados, firmas
Riesgo principal	Distribución y custodia de la clave	Validación de identidad y tamaño/algoritmo
Ejemplo	AES para datos almacenados	RSA/ECDSA en TLS

PCI DSS exige criptografía sólida para hacer PAN ilegible cuando se almacena y para proteger PAN durante transmisión en redes públicas abiertas (PCI DSS v4.0.1, Req 3.5.1, p. 90 LA; Req 4.2.1, p. 126 LA). La pregunta de examen suele esconder el error en el contexto: cifrado de almacenamiento no prueba cifrado en tránsito, y cifrado en tránsito no prueba que PAN almacenado sea ilegible.

Como assessor, identifica:

• Qué dato se protege: PAN, CHD, SAD, llave criptográfica o canal.
• Dónde se protege: base de datos, archivo, backup, API, navegador, terminal POI.
• Quién puede descifrarlo y dónde vive la llave.
• Si el mecanismo tiene evidencia operacional, no solo arquitectura.

El glosario define criptografía sólida como criptografía basada en algoritmos probados y aceptados por la industria, con longitudes de llave y prácticas de gestión adecuadas (PCI DSS v4.0.1, Anexo G, p. 394-408 LA). Para equivalencias de fortaleza, usa NIST como referencia técnica complementaria, no como sustituto del requisito PCI.

1.2 Algoritmos de cifrado y fortaleza equivalente

Regla de examen: no memorices una lista infinita; memoriza que el assessor debe verificar algoritmo, longitud de llave, configuración y gestión. Un algoritmo moderno mal configurado puede fallar igual que un algoritmo obsoleto.

Familia	Lectura práctica ISA	Riesgo típico	Referencia
AES-128/AES-256	Simétrico fuerte para datos y canales si se implementa correctamente	Gestión de llaves débil	PCI DSS Req 3.5.1/3.6
RSA-2048/RSA-3072	Asimétrico usado en certificados/intercambio de llaves	Tamaño insuficiente o certificado vencido	PCI DSS Req 4.2.1.1
TDES	Legado; revisar si sigue aceptable para el contexto específico	Vida útil y fortaleza degradada	Revisión criptográfica anual
ECC	Asimétrico moderno con menor tamaño de clave	Curva/configuración no aprobada	Revisión técnica

PCI DSS requiere revisar cipher suites y protocolos criptográficos al menos una vez cada 12 meses para confirmar que siguen siendo seguros (PCI DSS v4.0.1, Req 12.3.3, p. 298 LA). Esa revisión es distinta de operar criptografía fuerte diariamente.

Equivalencias útiles:

• AES-128 ofrece una referencia mínima común de fortaleza simétrica moderna.
• RSA-2048 se trata comúnmente como fortaleza aproximada de 112 bits; RSA-3072 se acerca a 128 bits.
• AES-256 no compensa por sí solo una llave expuesta o una custodia débil.
• TDES es una señal de alerta para revisar vigencia, modo y contexto.

(referencia técnica complementaria: NIST SP 800-57 Part 1 Rev. 5 para equivalencias de seguridad de claves; NIST SP 800-131A Rev. 2 para transición de algoritmos y longitudes de llave).

Trampa ISA: elegir “AES-256” como respuesta automática. La respuesta correcta puede ser revisar gestión de llaves, certificados, inventario o cipher suites, según el requisito citado.

1.3 Hashing vs cifrado: one-way vs two-way

Regla de examen: hashing es one-way; cifrado es two-way. Si alguien necesita recuperar el PAN original, no está usando hashing puro como mecanismo de recuperación.

Característica	Hashing	Cifrado
Reversibilidad	No reversible por diseño	Reversible con la llave
Uso típico	Verificación, integridad, PAN ilegible con hash con clave	Confidencialidad de datos
Pregunta clave	¿Hay salt/keyed hash y resistencia a ataques?	¿Dónde está la llave y quién puede descifrar?
Error común	Usar MD5/SHA-1 o hash sin clave para PAN	Cifrar pero exponer llave en el mismo entorno

PCI DSS permite métodos como cifrado, truncamiento, enmascaramiento y hash para proteger PAN almacenado, pero si se usa hashing para hacer PAN ilegible, el requisito específico exige hashes criptográficos con clave del PAN completo (PCI DSS v4.0.1, Req 3.5.1, p. 90 LA; Req 3.5.1.1, p. 93 LA).

El glosario define hashing como una función unidireccional que convierte datos en un compendio de longitud fija y debe resistir recuperación de entrada y colisiones prácticas (PCI DSS v4.0.1, Anexo G, p. 394-408 LA).

Como assessor:

• Pide diseño del método, no solo nombre del algoritmo.
• Verifica si el hash cubre PAN completo o solo fragmentos.
• Revisa si hay clave secreta para el hash cuando se usa para cumplir 3.5.1.1.
• Confirma que logs, reportes y backups no reintroducen PAN claro.

1.4 Algoritmos de hashing aceptables vs obsoletos

Regla de examen: MD5 nunca es respuesta segura para protección PCI; SHA-1 es obsoleto para nuevas protecciones criptográficas. SHA-256/SHA-3 son opciones modernas, pero PCI DSS exige el contexto correcto, especialmente hash con clave para PAN.

Algoritmo	Lectura para examen	Uso aceptable para proteger PAN
MD5	Obsoleto por colisiones prácticas	No
SHA-1	Obsoleto para resistencia moderna a colisiones	No como control nuevo
SHA-256	Familia SHA-2 moderna	Solo si el diseño cumple requisito aplicable
SHA-3	Familia moderna alternativa	Solo si el diseño cumple requisito aplicable
HMAC-SHA-256	Hash con clave	Candidato fuerte para 3.5.1.1

PCI DSS habla de hash criptográfico con clave para PAN almacenado cuando el hashing se usa para hacer ilegible el PAN; no basta decir “SHA-256” si no hay clave y diseño completo (PCI DSS v4.0.1, Req 3.5.1.1, p. 93 LA).

(referencia técnica complementaria: NIST SP 800-131A Rev. 2 desaconseja algoritmos obsoletos como MD5 para protección criptográfica; NIST FIPS 180-4 define SHA-2; NIST FIPS 202 define SHA-3).

Distractor típico: “hashing es irreversible, por tanto siempre saca de alcance”. No. El alcance depende de dónde vive el dato, el índice/token, el proceso, la llave y la capacidad de correlación.

1.5 DEK vs KEK: la regla “KEK >= DEK criptográficamente”

Regla de examen: DEK cifra datos; KEK cifra o protege llaves. La KEK debe tener fortaleza criptográfica al menos equivalente a la DEK que protege.

Término	Expansión	Rol
DEK	Data Encryption Key	Cifra datos, por ejemplo PAN almacenado
KEK	Key Encryption Key	Cifra/protege la DEK
HSM/KMS	Sistema de gestión	Custodia, controla uso, rotación y acceso

PCI DSS exige que las claves criptográficas usadas para proteger datos de cuenta estén protegidas contra divulgación y uso indebido (PCI DSS v4.0.1, Req 3.6, p. 94 LA). También exige procesos de gestión de llaves, incluyendo generación, distribución, almacenamiento, rotación/reemplazo, retiro y prevención de sustitución no autorizada (PCI DSS v4.0.1, Req 3.7, p. 105-113 LA).

La regla práctica:

• Una DEK puede rotar más seguido que una KEK.
• Una KEK no debe ser más débil que las DEK que protege.
• Si la KEK vive junto a la DEK cifrada sin controles, el diseño puede ser débil.
• El assessor debe revisar custodia, acceso y evidencia de lifecycle.

(referencia técnica complementaria: NIST SP 800-57 Part 1 Rev. 5 para jerarquías de llaves, criptoperiodos y fortaleza equivalente).

Trampa ISA: una opción dice “la KEK puede ser más débil porque solo cifra llaves”. Es falsa. Si cae la KEK, caen las DEK protegidas por ella.

1.6 Gestión de llaves: lifecycle, split knowledge, dual control, custodia

Regla de examen: la gestión de llaves es proceso, evidencia y separación de funciones. No basta tener HSM.

PCI DSS requiere proteger las claves criptográficas contra divulgación y uso indebido, restringir el acceso a custodios necesarios, almacenar claves de forma segura, y aplicar procedimientos documentados de gestión de llaves (PCI DSS v4.0.1, Req 3.6, p. 94 LA; Req 3.7, p. 105-113 LA).

Concepto	Qué significa	Evidencia típica
Lifecycle	Generar, distribuir, almacenar, rotar, retirar y destruir	Procedimientos, tickets, logs KMS/HSM
Custodia	Personas/roles autorizados a gestionar claves	Matriz de roles, aprobaciones
Split knowledge	Ninguna persona conoce la clave completa	Ceremonia de llaves, partes separadas
Dual control	Dos o más personas requeridas para operación sensible	Registros de ceremonia, controles HSM
Criptoperiodo	Tiempo permitido de uso de una llave	Política y evidencia de rotación

Como assessor:

• Verifica que la política describa quién puede hacer qué.
• Observa configuración real del HSM/KMS cuando aplique.
• Entrevista custodios para confirmar que el proceso se ejecuta.
• Busca llaves en scripts, variables, repositorios y backups.

Distinción clave: split knowledge protege conocimiento de la clave; dual control protege la ejecución de operaciones sensibles. Se relacionan, pero no son sinónimos.

1.7 Tokenización vs truncamiento vs enmascaramiento vs hashing

Regla de examen: estas técnicas no son intercambiables. La pregunta suele mezclar “mostrar”, “almacenar”, “recuperar” y “hacer ilegible”.

Técnica	Qué hace	¿Reversible?	Uso típico	Trampa
Tokenización	Reemplaza PAN por token y mantiene relación controlada	Sí, mediante vault/proceso	Reducir exposición de PAN en aplicaciones	El vault sigue en alcance
Truncamiento	Elimina parte del PAN completo	No sin recrear desde otra fuente	Almacenamiento/visualización limitada	No confundir con masking
Enmascaramiento	Oculta PAN al mostrarlo	No cambia el dato almacenado	Pantallas, recibos, reportes	PAN puede seguir claro en backend
Hashing	Genera resumen fijo one-way	No	Comparación/verificación	Debe cumplir requisitos de hash con clave si protege PAN

PCI DSS reconoce cifrado, truncamiento, enmascaramiento y hash como métodos de protección de PAN, pero cada uno tiene requisitos y límites propios (PCI DSS v4.0.1, Req 3.5.1, p. 90 LA). El estándar distingue enmascaramiento y truncamiento: el enmascaramiento oculta cuando se muestra; el truncamiento elimina un segmento del PAN completo (PCI DSS v4.0.1, Anexo G, p. 394-408 LA).

Regla de alcance: tokenizar no elimina mágicamente el alcance. El vault, el proceso de detokenización y los sistemas que pueden recuperar PAN siguen siendo críticos.

Referencias cruzadas:

• glosario.md para Hashing, Índice de Token, PAN y Truncamiento.
• resumen-requisitos.md Requisito 3 para evidencias de almacenamiento.
• pci-isa-exam-guide.md para la advertencia sobre cifrado y alcance.

2. Comunicaciones y redes

2.1 TLS 1.2/1.3 vs SSL/TLS 1.0/1.1 deprecados

Regla de examen: para redes públicas abiertas, PCI DSS exige protocolos de seguridad y criptografía sólida; SSL y primeras versiones de TLS son señales de alerta. TLS 1.2/1.3 son el baseline técnico moderno, salvo casos específicos y controlados de POS POI heredado.

Versión/protocolo	Lectura práctica	Tratamiento ISA
SSL 2.0/3.0	Obsoleto	No aceptar como control seguro
TLS 1.0/1.1	Primeras versiones, deprecadas	Señal de migración/justificación, especialmente POS POI legado
TLS 1.2	Baseline moderno común	Verificar configuración y cipher suites
TLS 1.3	Moderno	Verificar compatibilidad y configuración

PCI DSS requiere protocolos de seguridad y criptografía sólida para proteger PAN transmitido por redes públicas abiertas (PCI DSS v4.0.1, Req 4.2.1, p. 126 LA). También exige inventario de certificados/confiabilidad de claves asociadas a transmisión, incluyendo validez y no expiración cuando aplique (PCI DSS v4.0.1, Req 4.2.1.1, p. 129 LA).

El Apéndice A2 trata el uso de SSL y primeras versiones de TLS para conexiones de terminales POS POI con tarjeta presente; las nuevas implementaciones de terminales POS POI no deben usar SSL o primeras versiones de TLS como control de seguridad (PCI DSS v4.0.1, Apéndice A2, p. 356-363 LA).

(referencia técnica complementaria: NIST SP 800-52 Rev. 2 recomienda TLS 1.2 o TLS 1.3 para uso gubernamental; RFC 8996 depreca TLS 1.0 y TLS 1.1; RFC 8446 define TLS 1.3).

Trampa ISA: “usa TLS” no es evidencia suficiente. El assessor debe verificar versión, cipher suites, certificado, ruta, endpoint y que PAN realmente viaja protegido.

2.2 Redes confiables vs no confiables

Regla de examen: una red “interna” no es automáticamente confiable; una red pública abierta incluye Internet y otros entornos donde atacantes pueden acceder al tráfico.

PCI DSS exige proteger PAN con criptografía sólida cuando se transmite por redes públicas abiertas (PCI DSS v4.0.1, Req 4.2.1, p. 126 LA). El estándar explica que las redes públicas abiertas incluyen, entre otras, Internet, tecnologías inalámbricas, redes celulares y otras redes públicas abiertas (PCI DSS v4.0.1, Req 4.2.1, p. 126-128 LA).

Como assessor:

• Traza el flujo real de PAN, no solo el diagrama lógico.
• Identifica saltos por Internet, redes de terceros, Wi-Fi, celular, APIs externas y VPN.
• No confundas “cifrado por VPN” con cumplimiento automático: revisa versión, configuración y alcance.
• Si PAN cruza una red pública abierta, aplica Req 4.2.1.

Relación con scope:

• Un sistema que no procesa PAN pero puede impactar la seguridad del CDE puede estar en alcance.
• Un servidor DNS, NTP, logging o autenticación puede entrar por impacto en seguridad si soporta el CDE.
• La segmentación debe probarse; no basta declarar una zona confiable.

Ver high-risk-topics.md Tema 1 para alcance y segmentación.

2.3 DMZ: arquitectura web/db

Regla de examen: la DMZ reduce exposición, pero no prueba segmentación por sí sola. La arquitectura debe limitar tráfico entrante y saliente según necesidad de negocio.

PCI DSS exige controles de seguridad de red para restringir conexiones entrantes y salientes entre redes no confiables y componentes del sistema dentro del CDE (PCI DSS v4.0.1, Req 1.4, p. 57 LA). También exige mantener diagramas de flujo de datos de cuenta actualizados (PCI DSS v4.0.1, Req 1.2.4, p. 45 LA).

Patrón de evidencia:

• Diagrama de red y flujo de datos actualizado.
• Reglas NSC que permitan solo puertos, orígenes y destinos necesarios.
• Prueba de segmentación cuando se usa para reducir alcance.
• Logs de cambios y revisiones de reglas.

Trampa ISA: decir “la base de datos está detrás de la DMZ” no demuestra cumplimiento. El assessor debe validar reglas, rutas, exposición, segmentación y flujo de PAN.

2.4 Mensajes con estado vs sin estado

Regla de examen: un mensaje con estado conserva contexto de sesión o transacción; un mensaje sin estado contiene lo necesario para procesarse sin memoria previa. El glosario usa “stateful” como concepto técnico, pero PCI DSS evalúa controles, no pureza académica.

Tipo	Qué conserva	Ejemplo de riesgo
Mensaje con estado	Contexto previo, sesión, nonce, correlación	Sesión secuestrada o estado inconsistente
Mensaje sin estado	Información suficiente en cada request	Token expuesto o replay si no hay controles

Para PCI DSS, la pregunta relevante es:

• ¿Se transmite PAN o SAD?
• ¿El mensaje cruza red pública abierta?
• ¿El token/sesión permite impactar el CDE?
• ¿Los logs contienen datos sensibles?

Si el mensaje transporta PAN por una red pública abierta, aplica protección con criptografía sólida (PCI DSS v4.0.1, Req 4.2.1, p. 126 LA). Si el mensaje genera logs, los controles de auditoría y retención entran en juego (PCI DSS v4.0.1, Req 10.4.1, p. 246 LA; Req 10.5.1, p. 251 LA).

3. Controles de monitoreo técnico

3.1 IPS vs IDS

Regla de examen: IDS detecta y alerta; IPS puede prevenir/bloquear. PCI DSS permite técnicas de detección y/o prevención, pero exige monitoreo de tráfico sospechoso o anómalo en perímetro y puntos críticos del CDE.

Criterio	IDS	IPS
Acción primaria	Detectar y alertar	Detectar y bloquear/prevenir
Ubicación típica	Fuera de línea, TAP/SPAN, sensor	En línea con el tráfico
Riesgo operativo	Alert fatigue, falsos negativos	Falsos positivos que cortan tráfico
Evidencia	Alertas revisadas, reglas, cobertura	Políticas de bloqueo, eventos, bypass controlado

PCI DSS exige técnicas de detección y/o prevención de intrusiones para detectar y/o prevenir intrusiones en la red, monitorear tráfico en el perímetro del CDE y puntos críticos, y alertar al personal sobre sospechas de compromiso (PCI DSS v4.0.1, Req 11.5.1, p. 283 LA). Para service providers existe un requisito adicional sobre detección de canales de comunicación encubiertos de malware desde el 31 de marzo de 2025 (PCI DSS v4.0.1, Req 11.5.1.1, p. 284 LA).

Como assessor:

• Verifica cobertura, no solo existencia de herramienta.
• Pide ejemplos de alertas, tuning y respuesta.
• Revisa si los puntos críticos del CDE están cubiertos.
• Distingue IDS/IPS de vulnerability scanning y de FIM.

Trampa ISA: “instalar IDS” no cumple si no hay operación, monitoreo ni alertamiento.

3.2 FIM

Regla de examen: FIM detecta cambios en archivos críticos; no es lo mismo que detección de cambios en páginas de pago del navegador.

PCI DSS exige un mecanismo de detección de cambios, como FIM, que alerte ante modificación no autorizada de archivos críticos y compare archivos críticos al menos una vez por semana (PCI DSS v4.0.1, Req 11.5.2, p. 286 LA). También exige que service providers documenten y confirmen roles y responsabilidades de ciertos controles, incluyendo monitoreo de integridad cuando aplica a sus servicios (PCI DSS v4.0.1, Req 12.5.2.1, p. 306 LA).

El glosario define FIM como una solución que comprueba cambios, adiciones y eliminaciones de archivos críticos y notifica cuando se detectan cambios (PCI DSS v4.0.1, Anexo G, p. 394-408 LA).

Pregunta	Respuesta esperada
¿Qué archivos?	Sistema operativo, configuración, aplicaciones críticas y archivos definidos por la entidad
¿Frecuencia?	Comparación al menos semanal
¿Salida?	Alerta al personal
¿No es?	No es pen test, scan ASV ni monitoreo de página de pago

Trampa ISA: confundir Req 11.5.2 con Req 11.6.1. FIM mira archivos críticos; 11.6.1 evalúa cambios en páginas de pago como las recibe el navegador del consumidor.

3.3 NTP y sincronización temporal

Regla de examen: NTP no es un “servicio menor”; sin tiempo coherente no hay correlación confiable de logs ni análisis forense.

PCI DSS exige que los mecanismos de sincronización de la hora admitan una configuración coherente en todos los sistemas (PCI DSS v4.0.1, Req 10.6, p. 262 LA). Los relojes del sistema deben sincronizarse con tecnología de sincronización de tiempo, y NTP es un ejemplo de esa tecnología (PCI DSS v4.0.1, Req 10.6.1, p. 262-263 LA).

Requisitos clave:

• Usar uno o más servidores de tiempo designados.
• Solo los servidores centrales designados reciben hora de fuentes externas.
• La hora externa se basa en TAI o UTC.
• Los sistemas internos reciben hora solo de los servidores centrales designados.
• El acceso a datos/configuración de tiempo está restringido por necesidad de negocio.
• Cambios en configuración de tiempo en sistemas críticos se registran, monitorean y verifican.

(PCI DSS v4.0.1, Req 10.6.2, p. 263 LA; Req 10.6.3, p. 264 LA)

Por qué importa: cuando los relojes no están sincronizados, puede ser difícil o imposible comparar archivos de registro y establecer una secuencia exacta de eventos para análisis forense (PCI DSS v4.0.1, Req 10.6.1, p. 262-263 LA).

Trampa ISA: elegir solo “configurar zona horaria”. El requisito va a sincronización, fuentes confiables, restricción de cambios y evidencia.

3.4 Logging vs alerting

Regla de examen: logging registra; alerting dispara atención. PCI DSS usa ambos, pero en requisitos distintos.

Control	Función	Ejemplo
Logging	Registrar eventos para revisión, investigación y trazabilidad	Audit logs del Req 10
Alerting	Avisar con prontitud sobre condición sospechosa o falla	IDS/IPS, FIM, fallas de controles críticos
Retención	Mantener evidencia disponible	12 meses, 3 inmediatos
Revisión	Analizar registros con frecuencia correcta	Diario para logs críticos

PCI DSS exige revisar diariamente logs críticos y eventos de seguridad (PCI DSS v4.0.1, Req 10.4.1, p. 246 LA). Otros logs se revisan periódicamente según TRA (PCI DSS v4.0.1, Req 10.4.2, p. 248 LA; Req 10.4.2.1, p. 249 LA). Los logs deben conservarse al menos 12 meses, con al menos 3 meses disponibles inmediatamente para análisis (PCI DSS v4.0.1, Req 10.5.1, p. 251 LA).

PCI DSS también exige detectar y alertar con prontitud ante fallas de sistemas críticos de control de seguridad, como NSC, IDS/IPS, mecanismos de detección de cambios, anti-malware, controles de acceso físico y lógico, audit logging y segmentación cuando aplica (PCI DSS v4.0.1, Req 10.7.2, p. 256 LA).

Trampa ISA: una alerta no reemplaza la revisión diaria de logs críticos; una revisión diaria no reemplaza detección de fallas de controles críticos.

4. Pagos físicos y POI

4.1 PCI PTS

Regla de examen: PCI PTS evalúa dispositivos POI; PCI DSS evalúa el entorno y controles de la entidad. Que un terminal sea PTS aprobado no significa que el merchant cumpla PCI DSS.

El glosario define POI como hardware y software usado por comerciantes para aceptar pagos de clientes; puede incluir dispositivos POI, bloques PIN y otros componentes (PCI DSS v4.0.1, Anexo G, p. 394-408 LA). PCI DSS exige proteger dispositivos POI contra manipulación y sustitución no autorizadas (PCI DSS v4.0.1, Req 9.5, p. 230 LA).

Estándar	Foco	Qué NO prueba
PCI PTS	Seguridad del dispositivo de punto de interacción	Operación PCI DSS del comercio
PCI DSS	Ambiente, procesos, personas, sistemas y datos	Certificación de diseño del hardware POI

PCI DSS requiere mantener lista actualizada de dispositivos POI y revisar superficies de dispositivos para detectar manipulación o sustitución no autorizada (PCI DSS v4.0.1, Req 9.5.1.1, p. 230 LA; Req 9.5.1.2, p. 230 LA). La frecuencia y tipo de inspección se definen mediante TRA (PCI DSS v4.0.1, Req 9.5.1.2.1, p. 232 LA).

Trampa ISA: “el dispositivo es PCI PTS, por tanto no necesito inspecciones”. Falso. PCI DSS exige controles operativos sobre los POI desplegados.

4.2 Skimmers físicos y lógicos

Regla de examen: un skimmer puede ser físico o lógico. PCI DSS 9.5 se enfoca en dispositivos POI físicos; para e-commerce, mira scripts/páginas de pago y Req 11.6.1.

Tipo	Donde aparece	Señales
Skimmer físico	Terminal POI presencial	Carcasa alterada, lector sobrepuesto, sello roto
Skimmer lógico	Software, script, página de pago	Script no autorizado, endpoint extraño, cambio en checkout
Sustitución POI	Dispositivo reemplazado	Serial/ubicación no coincide con inventario

PCI DSS exige inspeccionar superficies de dispositivos POI para detectar manipulación o sustitución no autorizada (PCI DSS v4.0.1, Req 9.5.1.2, p. 230 LA). También exige capacitar al personal en entornos POI para que conozca intentos de manipulación o sustitución, comportamiento sospechoso y reporte de indicios (PCI DSS v4.0.1, Req 9.5.1.3, p. 233 LA).

Lista mínima de inspección visual:

• Número de serie y ubicación coinciden con inventario.
• Sellos, tornillos y carcasa sin alteración.
• No hay lectores superpuestos ni cables extraños.
• Pantalla y teclado coinciden con modelo esperado.
• Personal sabe a quién reportar sospechas.

Para skimming lógico en e-commerce, revisa high-risk-topics.md y Req 11.6.1 sobre detección de cambios en páginas de pago (PCI DSS v4.0.1, Req 11.6.1, p. 288 LA).

4.3 SAD pre vs post autorización

Regla de examen: SAD puede existir durante el proceso de autorización, pero no debe almacenarse después de la autorización salvo excepciones acotadas para emisores y servicios de emisión.

Datos de autenticación sensibles incluyen datos completos de pista, código de verificación de tarjeta y PIN/bloques PIN. PCI DSS prohíbe almacenar SAD después de autorización, incluso si está cifrado, salvo excepciones específicas para emisores y entidades que prestan servicios de emisión (PCI DSS v4.0.1, Tabla 3, p. 6 LA; Req 3.3, p. 78 LA).

Dato	Antes de autorización	Después de autorización
PAN	Puede procesarse si está dentro de scope y protegido	Puede almacenarse si hay necesidad y se hace ilegible
Track completo/chip equivalente	Puede existir para autorización	No se almacena, salvo excepción de emisor
CVV/CVC/CID	Puede usarse para autorización	No se almacena
PIN/bloque PIN	Puede usarse en autorización	No se almacena, salvo controles aplicables de emisor

Trampa ISA: “SAD cifrado después de autorización está permitido”. Falso para entidades no emisoras. El cifrado no convierte SAD post autorización en almacenamiento aceptable.

5. Flujos de pago end-to-end

5.1 Autorización, captura, liquidación y chargeback

Regla de examen: PCI DSS aplica donde se almacena, procesa o transmite CHD/SAD, y también a sistemas que pueden impactar la seguridad del CDE. El flujo de pago ayuda a ubicar cuándo aparece cada dato.

Etapa	Qué ocurre	Dato sensible típico	Pregunta ISA
Autorización	Se decide aprobar/rechazar	CHD y SAD en tránsito	¿Se almacena SAD después?
Captura	Merchant confirma monto	PAN/token, referencia	¿Qué se retiene y dónde?
Clearing/settlement	Redes/adquirente/emisor liquidan	Datos de transacción	¿Qué tercero impacta seguridad?
Chargeback	Disputa y evidencia	Recibos, PAN truncado, logs	¿Se expone PAN innecesariamente?

PCI DSS aplica al CDE, a componentes que almacenan/procesan/transmiten CHD/SAD, a componentes con conectividad sin restricciones, y a componentes que pueden impactar la seguridad de datos de cuenta (PCI DSS v4.0.1, sección “Alcance de los Requisitos de PCI DSS”, p. 9 LA).

5.2 Quién ve qué dato y dónde aplica PCI DSS

Regla de examen: no todo actor ve SAD, y no todo sistema que ve token queda fuera de alcance. Evalúa función, conectividad y capacidad de impacto.

Actor/sistema	Puede ver	Riesgo de alcance
Terminal POI	PAN/SAD durante autorización	POI, red, inventario e inspecciones
Checkout e-commerce	PAN ingresado por consumidor	Página de pago, scripts, transmisión
Gateway	CHD, tokens, autorización	TPSP, contrato, AOC, responsabilidad
Sistema interno de pedidos	Token o PAN truncado	Puede quedar dentro si impacta CDE
SIEM/logging	Logs de seguridad	En alcance si soporta o impacta CDE
NTP/DNS/auth	No ve PAN normalmente	En alcance si impacta CDE

La entidad mantiene responsabilidad por gestionar TPSP con quienes comparte datos de cuenta o que podrían impactar la seguridad del CDE; debe monitorear su estado de cumplimiento al menos anualmente (PCI DSS v4.0.1, Req 12.8.4, p. 318 LA).

Trampa ISA: “solo el gateway ve PAN, por tanto el merchant queda fuera”. Depende. Si el merchant aloja checkout, scripts, redirecciones, logs, DNS o sistemas que impactan la seguridad, puede seguir teniendo obligaciones.

6. Reglas mnemotécnicas para el examen

Regla	Memoria rápida	Requisito ancla
KEK >= DEK siempre	La llave que protege llaves no puede ser más débil	3.6/3.7
Hashing es one-way	Cifrado es reversible; hashing no	3.5.1.1
MD5 nunca	Obsoleto para protección criptográfica	NIST complementario
TLS 1.2 mínimo moderno	TLS 1.2/1.3 como baseline técnico actual	4.2.1 + NIST/RFC
PAN almacenado ilegible	Cifrado, truncamiento, tokenización o hash según diseño	3.5.1
SAD post autorización no	Ni siquiera cifrado, salvo excepción de emisor	3.3
IDS alerta, IPS bloquea	PCI exige detección y/o prevención operativa	11.5.1
FIM semanal	Archivos críticos, no páginas de pago	11.5.2
NTP sostiene logs	Sin hora coherente, la investigación falla	10.6
PTS no reemplaza DSS	Dispositivo aprobado no prueba operación segura	9.5
DMZ no prueba segmentación	Hay que validar reglas y pruebas	1.4/11.4.5
Chargeback expone evidencia	Revisar PAN en recibos, reportes y adjuntos	3.4/3.5

6.1 Matriz de evidencia por concepto

Usa esta matriz para transformar un concepto técnico en evidencia evaluable. En el examen, las respuestas correctas suelen mencionar evidencia concreta, no solo una tecnología.

Concepto	Evidencia documental	Evidencia observable	Entrevista clave
DEK/KEK	Diseño de llaves, procedimiento de rotación, matriz de custodios	Configuración HSM/KMS, logs de uso de llaves	Custodio de llaves y dueño de aplicación
Hashing PAN	Diseño de hashing, algoritmo, uso de clave	Repositorios de PAN, salida de hash, protección de clave	Arquitecto de datos
TLS	Inventario de certificados, estándar de cipher suites	Configuración de endpoints, escaneo TLS	Equipo red/app
DMZ	Diagrama de red y flujo de datos	Reglas NSC, rutas, segmentación	Arquitecto de red
IDS/IPS	Cobertura, reglas, playbooks de respuesta	Consola, alertas recientes, tuning	SOC
FIM	Lista de archivos críticos, configuración de frecuencia	Reportes semanales, alertas	Administrador de plataforma
NTP	Diseño de servidores de tiempo, fuentes externas aprobadas	Configuración NTP, logs de cambios	Administrador de sistemas
POI/PTS	Inventario POI, procedimientos de inspección	Dispositivo físico, serial, sellos	Personal de tienda
SAD	Política de retención, búsqueda de datos	Logs, tablas, backups, dumps	Dueño de pagos
Chargeback	Procedimiento de evidencia y redacción de PAN	Muestras de recibos/reportes	Operaciones de disputa

6.2 Distractores frecuentes y cómo descartarlos

Distractor	Por qué suena correcto	Cómo descartarlo
”El PAN está cifrado, queda fuera de alcance”	Cifrado reduce exposición	Si el sistema descifra, procesa o impacta el CDE, sigue relevante para scope
”Tokenización elimina PCI DSS”	El token no es PAN	El vault, detokenización y sistemas conectados pueden seguir en alcance
”SHA-256 siempre cumple”	Es un algoritmo moderno	Req 3.5.1.1 exige hash criptográfico con clave para PAN cuando se usa hashing
”TLS significa seguro”	TLS es protocolo esperado	La versión, cipher suite, certificado y ruta real son la evidencia
”La DMZ prueba segmentación”	DMZ es patrón correcto	Segmentación requiere controles y pruebas de efectividad
”IDS/IPS instalado cumple”	La herramienta existe	PCI DSS pide monitoreo, cobertura y alertamiento operativo
”FIM y 11.6.1 son lo mismo”	Ambos detectan cambios	FIM mira archivos críticos; 11.6.1 mira página de pago en navegador
”NTP es solo operación”	No toca PAN directamente	Soporta logs, forense e integridad temporal
”PTS cubre POI”	PTS evalúa dispositivo	PCI DSS exige inventario, inspección y capacitación operativa
”SAD cifrado se puede guardar”	Cifrado protege datos	SAD post autorización está prohibido salvo excepciones de emisor

6.3 Preguntas de control para autocorrección

Cuando revises una respuesta, aplica estas preguntas antes de marcarla como correcta:

Si la pregunta menciona…	Pregunta de control
PAN almacenado	¿El método hace ilegible el PAN y hay gestión de llaves o diseño equivalente?
Hash	¿Es hash con clave cuando se usa para proteger PAN?
Llaves	¿Hay lifecycle, custodia, rotación y protección contra uso indebido?
TLS	¿El canal cruza red pública abierta y hay criptografía sólida verificable?
Certificados	¿Existe inventario y están vigentes/no vencidos?
Red confiable	¿Hay evidencia de segmentación y rutas, o solo etiqueta de red interna?
DMZ	¿Se validaron reglas entrantes/salientes y flujos de datos?
IDS/IPS	¿Está cubierto el perímetro del CDE y puntos críticos?
FIM	¿Compara archivos críticos al menos semanalmente?
NTP	¿Los sistemas internos reciben hora de servidores centrales designados?
POI	¿La lista de dispositivos coincide con inspección física?
Skimmer	¿Es físico en POI o lógico en página/script de pago?
SAD	¿La autorización ya ocurrió?
Gateway/TPSP	¿Hay responsabilidad documentada y monitoreo de cumplimiento del tercero?
Chargeback	¿La evidencia expone PAN más allá de lo necesario?

6.4 Mini escenarios ISA

Escenario A: base de datos cifrada con AES-256.
Respuesta madura: pedir diseño de llaves, ubicación de KEK/DEK, custodios, rotación, acceso de aplicación y evidencia de que PAN está ilegible en repositorios, backups y logs. No concluir fuera de alcance solo por cifrado.

Escenario B: API de pagos expuesta por Internet con TLS.
Respuesta madura: validar Req 4.2.1, versión TLS, cipher suites, certificado, ruta de PAN, terminación TLS, logs y monitoreo. Si hay cambio de gateway o endpoint, revisar impacto en scope y documentación.

Escenario C: retail con terminales POI PTS aprobados.
Respuesta madura: distinguir aprobación del dispositivo de operación PCI DSS. Pedir inventario, inspecciones por TRA, capacitación contra sustitución/manipulación y evidencia de seriales/ubicaciones.

Escenario D: alerta FIM semanal sin revisión SOC.
Respuesta madura: FIM debe alertar, pero el valor de control depende de que el personal reciba, revise y responda. Revisar integración, alertas, tickets y fallas de controles críticos si aplica.

Escenario E: NTP externo configurado en cada servidor.
Respuesta madura: PCI DSS espera servidores de tiempo designados; solo los centrales reciben hora externa, y los internos reciben de esos centrales. Revisar fuentes aceptadas, restricción de cambios y logging.

Escenario F: chargeback con recibo completo.
Respuesta madura: revisar si el recibo expone PAN completo innecesariamente, si hay masking/truncamiento, quién accede a la evidencia y si el repositorio de disputas queda dentro del análisis PCI.

6.5 Orden recomendado de descarte en preguntas difíciles

1. Identifica el dato: PAN, CHD, SAD, llave, token, log o evidencia.
2. Identifica el momento: pre autorización, post autorización, almacenamiento, transmisión o disputa.
3. Identifica el sistema: CDE, conectado a, impacto en seguridad, tercero o fuera de alcance probado.
4. Identifica el requisito: 3 para almacenamiento, 4 para transmisión, 9 para POI, 10 para logs/NTP, 11 para monitoreo técnico, 12 para governance/TPSP.
5. Descarta respuestas que reemplazan evidencia por tecnología nominal.
6. Descarta respuestas que usan TRA para frecuencias fijas.
7. Descarta respuestas que confunden estándar de dispositivo con operación del entorno.
8. Si dos respuestas parecen correctas, elige la que pide evidencia verificable y cita el requisito más específico.

6.6 Tabla de confusiones por requisito

Confusión	Requisito correcto	Forma corta de recordarlo
PAN almacenado vs PAN transmitido	3.5.1 vs 4.2.1	Reposo es Req 3; tránsito es Req 4
Hash PAN vs contraseña	3.5.1.1 vs 8.3.x	PAN ilegible no es autenticación de usuario
Certificado TLS vs revisión cripto anual	4.2.1.1 vs 12.3.3	Inventario no reemplaza revisión de vigencia técnica
DMZ vs segmentación probada	1.4 vs 11.4.5/11.4.6	Arquitectura no equivale a prueba
IDS/IPS vs scan de vulnerabilidades	11.5.1 vs 11.3.x	Monitorear tráfico no es buscar vulnerabilidades
FIM vs tamper detection web	11.5.2 vs 11.6.1	Archivos críticos no son páginas vistas por consumidor
NTP vs retención de logs	10.6 vs 10.5.1	Hora coherente no es archivo conservado
POI inventory vs POI inspection	9.5.1.1 vs 9.5.1.2	Lista no es revisión visual
POI PTS vs PCI DSS	PTS vs 9.5.x	Producto aprobado no sustituye operación
TPSP AOC vs responsabilidad propia	12.8.x	Tercero validado no transfiere responsabilidad

6.7 Términos que conviene decir igual que el estándar

Mantén la terminología estable para evitar respuestas ambiguas:

Usa	Evita
Criptografía sólida	”Cifrado fuerte” sin contexto
Redes públicas abiertas	”Internet” como único caso
Datos de autenticación sensibles (SAD)	“Datos sensibles” genérico
Dispositivo POI	”POS” para todo
Monitoreo de la integridad de los archivos (FIM)	“Control de cambios” genérico
Mecanismos de sincronización de la hora	”Zona horaria”
Técnicas de detección y/o prevención de intrusiones	”Firewall” como sustituto
Análisis de riesgos específico (TRA)	“Risk assessment” empresarial

Referencias cruzadas

• glosario.md: Hashing, Hash Criptográfico con Clave, IDS, IPS, FIM, NTP, POI, Truncamiento y Criptografía Sólida.
• resumen-requisitos.md: Requisitos 1, 3, 4, 9, 10, 11 y 12.
• high-risk-topics.md: alcance, segmentación, significant change, FIM, IDS/IPS y páginas de pago.
• pci-isa-exam-guide.md: mentalidad de assessor, alcance, evidencia y trampas de cifrado.
• periodicity-bau-significant-change.md: revisión anual de cipher suites, inspecciones POI por TRA, FIM semanal y logs diarios.

Checklist final para repaso

• Si aparece DEK/KEK, busca fortaleza equivalente, custodia y lifecycle.
• Si aparece MD5 o SHA-1, sospecha algoritmo obsoleto.
• Si aparece SHA-256, verifica si el contexto exige hash con clave.
• Si aparece TLS, pide versión, cipher suite, certificado y ruta real.
• Si aparece DMZ, no confundas diseño con prueba de segmentación.
• Si aparece IDS/IPS, valida cobertura y alertas, no instalación.
• Si aparece FIM, recuerda archivos críticos y frecuencia semanal.
• Si aparece NTP, conecta con logs, forense y restricción de cambios.
• Si aparece PTS, separa seguridad del dispositivo de cumplimiento PCI DSS.
• Si aparece skimmer, distingue POI físico de skimming lógico en e-commerce.
• Si aparece tokenización, identifica vault y detokenización.
• Si aparece chargeback, piensa en evidencia, recibos y exposición de PAN.