PCI DSS en Costa Rica: pruebas de penetración del requisito 11.4

PCI DSS es un estándar privado del PCI Security Standards Council. La obligación de seguirlo llega por contrato, con la marca de tarjeta o con el adquirente, no por una norma de la Superintendencia. El Acuerdo CONASSIF 5-24, el reglamento de TI que rige a bancos, financieras, cooperativas, aseguradoras y operadoras de pensiones desde julio de 2024, no menciona PCI DSS en su texto.

Para un banco supervisado que emite tarjetas, las dos cosas conviven. El Art. 33 de ese reglamento le pide "programas de análisis de vulnerabilidades y pruebas" cada año, con tipos y alcance según el riesgo. El requisito 11.4 de PCI DSS le pide pentest interno y externo al menos una vez cada 12 meses. Si el alcance se diseña pensando en ambos, una sola prueba bien documentada puede servir de evidencia en los dos frentes. La entidad decide si la usa así.

En el caso de las fintech y procesadores que atienden a bancos, hay una presión adicional. El Art. 25 del mismo reglamento obliga a la entidad supervisada a comprobar que sus proveedores de TI gestionan la seguridad de la información según los requisitos que ella define. El banco con el que usted trabaja puede pedirle su último informe de pentest aunque PCI DSS no se lo exija.

La versión 4.0.1 se publicó en junio de 2024. Los requisitos que la versión 4.0 marcó como buenas prácticas hasta el 31 de marzo de 2025 ya son obligatorios. El 11.4 se divide así:

• 11.4.1. La entidad define, documenta y aplica una metodología. Debe cubrir todo el perímetro del CDE y los sistemas críticos, probar desde dentro y desde fuera de la red, validar los controles de segmentación y de reducción de alcance, incluir pruebas de la capa de aplicación y de la capa de red, y conservar los resultados y las correcciones al menos 12 meses.
• 11.4.2 y 11.4.3. Pentest interno y externo al menos una vez cada 12 meses y después de cualquier cambio o actualización importante de infraestructura o aplicaciones. Lo hace un recurso interno calificado o un tercero calificado, con independencia organizacional. No tiene que ser QSA ni ASV.
• 11.4.4. Las vulnerabilidades explotables se corrigen según el riesgo definido en el requisito 6.3.1, y el pentest se repite para verificar las correcciones.
• 11.4.5. Si la entidad usa segmentación para aislar el CDE, la prueba la cubre al menos cada 12 meses y después de cualquier cambio en esos controles.
• 11.4.6 y 11.4.7. Los proveedores de servicio prueban la segmentación cada seis meses, y los proveedores multiinquilino apoyan el pentest externo de sus clientes.

El CDE es el entorno de datos de titulares de tarjeta: los sistemas que guardan, procesan o transmiten esos datos y los que se conectan con ellos. El pentest vale lo que vale su alcance. Antes de pedir cotizaciones, tenga a mano estos documentos:

• El diagrama de red con el CDE marcado y los puntos donde se conecta con el procesador, la red interna y los proveedores.
• El flujo del dato de tarjeta, desde que entra por la aplicación, el datáfono o la API hasta que sale hacia la marca o el procesador.
• La lista de controles de segmentación (firewalls, VLAN, grupos de seguridad en la nube) que separan el CDE del resto.
• Las IP públicas y las aplicaciones expuestas a internet que tocan el CDE, con sus roles de usuario.

El estándar define con precisión qué es cada prueba. La interna se hace desde dentro del CDE y hacia el CDE, tanto desde redes internas de confianza como desde las que no lo son. La externa cubre el perímetro expuesto y los sistemas críticos accesibles desde redes públicas. Un pentest que solo mira la red externa deja sin evidencia la mitad del requisito.

La prueba de aplicación debe buscar, como mínimo, las vulnerabilidades que lista el requisito 6.2.4: inyecciones, ataques a estructuras de datos, abuso de la criptografía, ataques a la lógica de negocio y al control de acceso. Para una fintech costarricense cuyo producto es una app o una API de pagos, esa suele ser la parte más importante del alcance.

En Toukan, cada hallazgo se confirma a mano y el informe ejecutivo y técnico lo firma quien acordó el alcance y dirigió la prueba. Un informe con hallazgos sin confirmar no le sirve a quien evalúa el entorno.

Si su empresa procesa, transmite o guarda datos de tarjeta por cuenta de otros, PCI DSS la trata como proveedor de servicio. El requisito 11.4.6 le pide probar la segmentación cada seis meses y después de cada cambio en esos controles, el doble de lo que se le exige a un comercio. Si además atiende a varios clientes sobre la misma infraestructura, el 11.4.7 le pide apoyar el pentest externo de esos clientes, dándoles acceso o evidencia de una prueba comparable.

Planifique el calendario con eso en mente. Una prueba de segmentación cada semestre, más el pentest anual y los que provoquen los cambios importantes, suman varias pruebas al año. Cotizarlas juntas desde el inicio suele salir más ordenado que cotizar cada una cuando llega la fecha.

El requisito 11.3.2 pide escaneos externos de vulnerabilidades cada tres meses, hechos por un Approved Scanning Vendor (ASV) del PCI SSC. Es otro servicio. Toukan no es ASV y no vende escaneos trimestrales PCI.

Tampoco somos QSA. El informe de pentest es evidencia del requisito 11.4 que su organización presenta a su QSA o a quien evalúa su entorno. El PCI SSC no permite usar marcas como "PCI Compliant" o "PCI Certified", ni sellos que sugieran cumplimiento, así que ningún proveedor de pentest debería ofrecerle uno.

El paquete de Auditoría y PCI DSS de Toukan arranca en USD 5,500. Cubre la red externa y una aplicación web en una sola prueba de 8 días. La red interna y las pruebas de segmentación se cotizan aparte, según el tamaño del CDE. Del contrato firmado al informe pasan de 2 a 4 semanas.

El requisito 11.4.4 pide repetir la prueba para verificar lo corregido. Por eso la verificación de las correcciones viene incluida dentro de 90 días. Ese plazo da margen a los equipos que corrigen a través de un comité de cambios. El resultado queda por escrito y se suma a los 12 meses de registros que pide el 11.4.1.

Si su empresa necesita además ordenar su sistema de gestión de seguridad para ISO 27001 o para el Acuerdo CONASSIF 5-24, el mismo alcance puede servir de base para el análisis de brechas.