Blog
Ciberseguridad
auditoría de seguridad, cardholder data environment, ciberseguridad, cumplimiento pci, estándares de seguridad, ethical hacking, metodología pentest, normativa pci, pci compliance, pci dss, penetration testing, pentest genérico, pentest pci, pruebas de penetración, red team, retesteo, security audit, segmentación de red, seguridad de la información, seguridad ofensiva
David
0 Comentarios
Pentest genérico vs Pentest PCI: una mirada técnica desde el lado del pentester
Cuando alguien dice “haremos un pentest”, esa frase puede significar muchas cosas: un test de red, una auditoría web, una revisión interna o incluso un simulacro de Red Team. En muchos casos se trata de una evaluación “genérica”. Pero cuando el objetivo es cumplir con PCI DSS (Payment Card Industry Data Security Standard), el escenario cambia por completo: aparecen normas, requisitos específicos, validaciones de segmentación y obligaciones de retesteo.
En este artículo analizo, desde la perspectiva de un pentester, todas las diferencias técnicas y procedimentales entre un pentest genérico y un pentest PCI, explicando por qué el segundo es mucho más que “un pentest normal con un sello de compliance”.
¿Qué entendemos por “pentest genérico”?
Un pentest genérico es una auditoría ofensiva sin obligación reglamentaria. Su propósito principal es detectar vulnerabilidades, demostrar vectores de ataque y ofrecer recomendaciones. El alcance es negociable: puede centrarse en una aplicación, una red interna, un entorno cloud o un API. La metodología es flexible (PTES, OSSTMM, NIST, OWASP, etc.), y el nivel de formalidad depende del cliente.
En resumen: el foco está en la seguridad técnica, no en el cumplimiento normativo.
Qué es un pentest PCI
Un pentest PCI es una auditoría ofensiva regulada por el estándar PCI DSS. Su función es validar la seguridad del Cardholder Data Environment (CDE) y demostrar que los controles implementados son eficaces. No se trata solo de encontrar vulnerabilidades, sino de probar y evidenciar que el entorno cumple los requisitos definidos por el PCI Security Standards Council.
Los requisitos formales están detallados en la guía oficial Penetration Testing Guidance v1.1, que establece qué metodologías son válidas, cómo definir el alcance y qué evidencia debe generarse.
Diferencias fundamentales
| Aspecto | Pentest genérico | Pentest PCI DSS |
|---|---|---|
| Motivo | Mejorar la seguridad general | Demostrar cumplimiento con PCI DSS |
| Obligatoriedad | Voluntario | Obligatorio para quienes manejan datos de tarjetas |
| Alcance | Negociable | Debe cubrir todo el CDE y sistemas conectados |
| Metodología | Libre (PTES, OSSTMM, etc.) | Debe basarse en una reconocida por PCI SSC |
| Segmentación | Opcional | Debe probarse la eficacia del aislamiento de red (guía oficial) |
| Frecuencia | Depende del cliente | Anual y tras cambios significativos (DeepStrike, 2025) |
| Retesteo | Opcional | Obligatorio, con evidencia de corrección |
| Tipo de prueba | Puede ser black, white o grey box | Solo white o grey box, según guía PCI |
| Informe | Flexible | Estructurado, con pasos, evidencia y firmas |
| Independencia | No siempre exigida | Debe garantizarse (ver Schellman PCI FAQ) |
| Coste | Más económico | Más elevado (por formalidad y extensión) |
Aspectos técnicos clave
1. Delimitación del CDE
El pentest PCI debe cubrir no solo los servidores que procesan pagos, sino también cualquier sistema o red conectada que pueda influir en la seguridad del CDE. Esto incluye firewalls, proxies, sistemas de backup, entornos cloud y redes de administración. Cualquier fallo en la definición del alcance invalida el test.
2. Metodología reconocida
La guía Penetration Testing Guidance v1.1 exige que se utilice una metodología reconocida (PTES, NIST SP 800-115, OSSTMM o equivalente). El proceso debe documentarse: descubrimiento, explotación, escalado, pos-explotación y reporte.
3. Nivel de conocimiento permitido (black, grey, white box)
En un pentest genérico, el cliente y el pentester pueden acordar libremente el nivel de información proporcionada: desde un black box (sin información previa, simulando un atacante externo), hasta un white box (con acceso total al código, documentación y credenciales). Este tipo de flexibilidad permite ajustar el test según los objetivos técnicos o económicos.
Sin embargo, en un pentest PCI, la situación es diferente. La propia guía de PCI SSC recomienda explícitamente realizar pruebas en modalidad white box o grey box, nunca black box, porque el objetivo no es simular un atacante genérico sino validar controles y segmentación de manera exhaustiva y verificable. Un test ciego (black box) podría pasar por alto activos críticos o dejar sin validar zonas del CDE, lo que lo haría inválido como evidencia de cumplimiento.
En otras palabras: un pentest PCI no busca medir el “misterio” de la defensa, sino su eficacia comprobada.
4. Pruebas de segmentación
Uno de los mayores errores de las empresas es asumir que su segmentación de red “funciona”. PCI obliga a validarlo: se deben realizar pruebas activas para demostrar que un sistema fuera del CDE no puede acceder al interior. Blaze InfoSec lo considera uno de los puntos más críticos del proceso.
5. Frecuencia y disparadores
El test debe realizarse al menos una vez al año y cada vez que se realicen cambios significativos en la infraestructura. Esto incluye migraciones, actualizaciones mayores, nuevos sistemas o cambios de topología de red (DeepStrike, 2025).
6. Retesteo obligatorio
En PCI, después de la corrección de vulnerabilidades debe hacerse un retest documentado. El auditor necesita evidencia de que las fallas se mitigaron eficazmente. Esto es obligatorio según la sección 11.3 del estándar.
7. Estructura del informe
El informe PCI debe contener metodología, herramientas, resultados, evidencia (capturas, logs, tiempos), y conclusiones claras. También debe reflejar la independencia del tester y la trazabilidad completa desde el hallazgo hasta la corrección. Tevora y LevelBlue publican ejemplos de estructuras válidas.
8. Independencia
El pentester no puede formar parte del equipo que mantiene los sistemas evaluados. La independencia garantiza objetividad, y es uno de los puntos que los auditores revisan con más atención (Schellman).
9. Gestión de “weaknesses”
Desde la versión 4.0, PCI obliga a identificar no solo vulnerabilidades explotables, sino también debilidades de seguridad que puedan contribuir a un riesgo futuro. Schellman y BishopFox explican cómo esto amplía el alcance técnico.
Conclusión
Un pentest genérico y un pentest PCI pueden parecer similares, pero en la práctica difieren en cada etapa: desde el alcance hasta la entrega final. El primero busca descubrir vulnerabilidades; el segundo busca demostrar cumplimiento verificable. No basta con hacer un buen pentest: hay que hacerlo bajo las reglas del juego que marca PCI DSS.
Y por diseño, esas reglas no son compatibles con la opacidad de un black box: el cumplimiento requiere transparencia y trazabilidad total.
Para las organizaciones que manejan datos de tarjeta, un pentest PCI no es un lujo —es un requisito de supervivencia.
Referencias
- PCI Security Standards Council — Penetration Testing Guidance v1.1
- Information Supplement 11.3: Penetration Testing
- DeepStrike — PCI DSS Penetration Testing 2025 Guide
- Blaze InfoSec — PCI Penetration Testing Guide
- Schellman — PCI DSS Penetration Testing FAQ
- Tevora — Understanding PCI Penetration Testing and Vulnerability Scanning Requirements
- LevelBlue — PCI DSS and Penetration Testing
- BishopFox — PCI DSS 4.0 Expert Breakdown
- PCI SSC — Scoping and Segmentation Guidance v1.1
Publicar comentario