Desde BOTECH FPI impulsamos el cumplimiento PCI Data Security Standard (PCI DSS) para ayudar a

nuestros clientes a:

 Minimizar el fraude.
 Apoyar a las organizaciones en la implementación de buenas prácticas de seguridad recogidas en la
norma.

PCI DSS, gestionada por el “PCI Security Standards Council” (PCI SSC), es un estándar de seguridad de
obligado cumplimiento dentro de la industria de los medios de pago y nace como resultado de un esfuerzo de
unificación de sus propios programas de seguridad por parte de las marcas VISA, MasterCard, Discover, JCB y
AMEX.

Auditoría y certificación PCI DSS

Avisor Technologies Caribe S,A. es representante exclusivo para la República Dominicana de la firma IQ Information
Quality, primera y única compañía colombiana que ha obtenido la certificación como QSA (Qualified Security Assessor)
dada por el PCI Security Standards Council para realizar las evaluaciones en sitio del cumplimiento de PCI DSS, para
bancos, adquiriente o emisores, comercios y proveedores de servicio para la región de América Latina y el Caribe.

El PCI DSS consiste en un grupo de requerimientos desarrollados para reducir el fraude y aumentar la seguridad de los
datos relacionados con la información de las tarjetas de crédito o débito.

Las normas de seguridad de datos de la industria de  pago detallan los requisitos de seguridad para los bancos
adquirientes o emisores, comercios y proveedores de servicio que almacenan, procesan o transmiten datos de los
tarjeta habientes.

El PCI DSS está dividido en doce requerimientos de seguridad  que están organizados en las siguientes seis categorías...

Medotología

La metodología aplicada tiene las siguientes fases:

1. Definición del alcance:

Identifica los procesos de negocio y los canales involucrados en la información de los tarjetahabientes y la
infraestructura que lo soporta.

2. GAP Análisis:

Permite identificar la brecha existente entre las prácticas de la organización y los requerimientos de la norma
PCI DSS. Se definen en caso de restricciones de negocio o técnicas, los controles compensatorios.

3. Plan de acción:

Permite identificar los controles a implementar para obtener el cumplimiento.

4. Evaluación de cumplimiento:

Evalua los controles de la norma PCI DSS o los controles compensatorios propuestos con el fin de verificar el
cumplimiento y reportar a las marcas.
Los 12 requisitos PCI DSS
Los 12 requisitos PCI DSS son un conjunto de controles de seguridad que las empresas están obligadas a
implementar para proteger los datos de las tarjetas de crédito y cumplir con el Estándar de Seguridad de Datos
para la Industria de Tarjetas de Pago (PCI DSS). Los requisitos han sido desarrollados y mantenidos por el
Consejo de Normas de Seguridad de la Industria de Tarjetas de Pago (PCI). 

Cualquier organización que reciba tarjetas de pago, incluyendo tarjetas de débito y crédito, deberá cumplir con
los 12 requisitos de forma directa o bien a través de un control de compensación. No obstante, los controles de
compensación no siempre se admiten y deben ser aprobados bajo un criterio de caso por caso, por parte de un
asesor de seguridad cualificado de la PCI (QSA PCI). El incumplimiento de los 12 requisitos PCI DSS puede
derivar en multas o en la finalización de los privilegios de procesamiento de tarjetas de crédito.

He aquí los 12 requisitos PCI DSS:

1. Instalar y mantener una configuración de firewall para proteger los datos de los titulares de tarjetas.
2. No utilizar los valores predeterminados suministrados por el proveedor para las contraseñas del sistema y
otros parámetros de seguridad.
3. Proteger los datos almacenados de los titulares de tarjetas. 
4. Cifrar la transmisión de los datos de los titulares de tarjetas a través de redes públicas abiertas.
5. Usar y actualizar con regularidad el software antivirus. 
6. Desarrollar y mantener sistemas y aplicaciones seguras.
7. Limitar el acceso a los datos de los titulares, únicamente a lo que los negocios necesiten saber. 
8. Asignar una identificación única a cada persona con acceso a una computadora. 
9. Restringir el acceso físico a los datos de los titulares de tarjetas.
10. Rastrear y monitorear todo acceso a los recursos de la red y a los datos de titulares de tarjetas. 
11. Probar con regularidad los sistemas y procesos de seguridad.
12. Mantener una política que aborde la seguridad de la información
Cómo debe cumplir su empresa el estándar PCI-
DSS?
Existe una creencia errónea en relación al cumplimiento de PCI-DSS. Veremos distintos casos y cómo debe
implementarse según el tipo y tamaño de empresa.

Corrían los primeros años de la década de 2000 y los casos de fraude con tarjetas de pago (crédito y débito)
iban en aumento en forma alarmante. En vistas de esto, en 2006 las empresas de tarjetas más importantes
(VISA, Mastercard, American Express, Discover y JCB) crearon el PCI-SSC (Payment Card Industry –
Security Standard Council), cuya piedra fundamental fue el estándar conocido como PCI-DSS (Payment Card
Industry – Data Security Standard).

El estándar PCI-DSS actualmente va por la versión 3.1 (la última en español es aún la 3.0) y define los
requerimientos mínimos de seguridad de los datos que debe cumplir cualquier organización que transmita,
procese o almacene información de tarjetas de pago. Se entiende por información de tarjeta el número PAN
completo (es el número de 16 dígitos que se encuentra al frente de la tarjeta), el nombre del tarjetahabiente, la
fecha de expiración y el código de servicio (código de 3 o 4 dígitos que se encuentra en la banda magnética).

Pero para cerrar una transacción no es necesario contar con todos estos datos, con lo cual se suelen utilizar sólo
algunos de ellos en simultáneo, dependiendo de la forma de validación. Adicionalmente, son considerados
datos sensibles el código de seguridad (CVC o CVV), la información completa de la banda magnética (o el
equivalente en las tarjetas chip) y los PINs, ya que estos datos son los que se utilizan como códigos de
autenticación para autorizar las transacciones de pago.

¿Quiénes deben cumplir el estándar PCI-DSS?

En el mercado existe una creencia errónea en relación al cumplimiento de este estándar; se piensa que si la
compañía es pequeña o realiza pocas ventas con tarjetas, no está en la obligación de cumplirlo. El consorcio
PCI define claramente que no importa si la organización es grande o pequeña: independientemente de si
vende productos o servicios, o si es una organización con o sin fines de lucro, mientras utilice este tipo de datos
debe cumplir con el estándar. Hay información específica para pequeños comerciantes disponible.

Lo que sí cambiará dependiendo de la cantidad de transacciones anuales que la organización realice, es el modo
en que su cumplimiento será auditado. Las compañías de tarjetas de pago han establecido cuatro niveles, cuyas
definiciones varían levemente entre una y otra compañía. Pero en lo que todas coinciden es que aquellas
organizaciones que procesen más de seis millones de transacciones anuales (Nivel 1 de la clasificación),
deben ser auditadas por una empresa auditora habilitada por el consorcio PCI.

Estas empresas son conocidas como QSA (Qualified Security Assessors). Usualmente dentro del grupo de las
empresas Nivel 1 encontramos supermercados, líneas aéreas, tiendas de retail y grandes tiendas de ventas
online. Para conocer más precisiones sobre las definiciones de los distintos niveles, pueden visitar estos enlaces
de VISA y de MASTERCARD con sus propias clasificaciones.

Sin embargo, la mayoría de las organizaciones, entre las cuales posiblemente se encuentre la suya, están
alcanzadas por los Niveles 2, 3 y 4. La ventaja en estos casos es que éstas no son auditadas por un QSA, sino
mediante un cuestionario de autoevaluación denominado SAC (Self-Assessment Questionaire). Este
cuestionario contiene los 12 requerimientos y los subrequerimientos del estándar PCI para que la organización
complete si cumple o no con cada uno de ellos.

De más está decir que debe responderse en función del nivel de cumplimiento real, ya que el SAC funciona
como una Declaración Jurada de cara a las empresas de tarjetas de pago. Debe ser completado por la
organización, firmado por el responsable de su cumplimiento y enviado a las empresas de tarjetas de pago. Este
proceso suele hacerse anual o bi-anualmente dependiendo de la organización y del nivel al que pertenece.

Eventualmente las empresas de tarjetas pueden pedir evidencias de cumplimiento de los requerimientos, y en
caso de que alguno de ellos no se cumpla, también pueden pedir que se proponga un plan para implementar la o
las medidas de seguridad que le den cumplimiento. Incluso cuando por las características del negocio no es
posible cumplir con un requerimiento PCI específico, es totalmente válido mitigar el riesgo asociado
implementando controles compensatorios.

Un punto importante es que los requerimientos planteados en el estándar están alineados con otros Frameworks
de Seguridad, como por ejemplo ISO 27001. Y al igual que en el caso de ISO 27001, el cumplimiento del
estándar no depende solamente de las áreas de sistemas y tecnología, sino de toda la organización,
especialmente de los máximos directivos. Las áreas de IT o sistemas tienen la responsabilidad de implementar y
mantener las medidas o controles de seguridad.

Además, no dejan de ser en muchos casos, implementaciones tecnológicas del sentido común. Probablemente
usted no dejaría anotado en un papel sobre un escritorio, los datos de las tarjetas de pago de sus clientes.
Almacenar esos mismos datos en una aplicación o archivo excel sin el nivel de seguridad adecuado, es el
equivalente tecnológico a dejar el papel en el escritorio.

Lo que vale la pena remarcar en estos casos es que las organizaciones no necesariamente deben incurrir en
altos costos para cumplir con el estándar. No es mandatorio que las empresas contraten una consultora externa
para dar cumplimiento al estándar, aunque a veces se gana en salud mental y al final termina siendo más rápido
y económico. Con perseverancia, conocimiento de la organización, análisis y trabajo, la propia organización
puede avanzar por su cuenta y cumplir con los requerimientos.

En próximos artículos trataremos algunas recomendaciones prácticas que faciliten a las pequeñas y medianas
empresas cumplir con el estándar con el menor esfuerzo posible.

Llegan los nuevos estándares para el software de

pagos
PCI SSC, el Payment Card Industry Security Standards Council, ha anunciado nuevos estándares de
seguridad para el diseño, desarrollo y mantenimiento del software de pagos.

PCI SSC (Payment Card Industry Security Standards Council) ha publicado el PCI Secure Software
Standard, el estándar de software seguro para la industria de tarjetas de pago, y el PCI Secure Lifecycle
(Secure SLC) Standard, el estándar de ciclo de vida segura de para la industria de tarjetas de pago, como parte
de un nuevo PCI Software Security Framework. Este marco de trabajo es un conjunto de estándares de
seguridad de software y programas asociados para el diseño, desarrollo y mantenimiento seguro de un software
de pagos moderno que tiene en cuenta no sólo nuevas arquitecturas de software, sino nuevo métodos de
desarrollo, como DevOps y la entrega continua. El nuevo estándar podría reemplazar el PCI Payment
Application Data Security Standard (PA-DSS).

PCI Secure Software Standard recoge y resumen los requisitos de seguridad, así como los procedimientos de
evaluación para garantizar que el software de pago proteja adecuadamente las transacciones y los datos. El
estándar se centra en configuraciones seguras por defecto, la identificación de activos críticos, la protección de
datos confidenciales, el control de acceso y autenticación, la detección de ataques y una guía de seguridad para
los proveedores.

“Este estándar en similar al Payment Application Data Security Standard (PA-DSS) de muchas maneras”, ha
dicho Troy Leach, CTO de PCI SSC, en un comunicado, añadiendo que “el objetivo de ambos estándares es
tener una forma de demostrar la protección continua de los datos de pago por parte del software que
almacena, procesa o transmite esa información, y que los proveedores de software tengan una manera de
demostrar una evaluación de seguridad independiente del software para lograr ese objetivo”.

Explica el directivo que PA-DSS se centra en el desarrollo de software y los principios de gestión del ciclo de
vida para la seguridad en el software de pago tradicional para ayudar a los comerciantes a mantener el
cumplimiento de las normas PCI DSS, mientras que PCI Software Security Standards se extiende más allá, para
abordar la capacidad de recuperación general de la seguridad del software, y que este marco proporciona
una nueva metodología y un nuevo enfoque para validar la seguridad del software; “no se excluyen
mutuamente, pero ofrecen un enfoque progresivo que permite alternativas adicionales para demostrar prácticas
seguras de software”.

I DSS responde a las siglas Payment Card Industry Data Security Standard y comprende un framework o
marco de referencia para certificar que las entidades al él adscritas cumplen con unas normativas de seguridad
en sistemas informáticos, de red y datos.

Este estandar de seguridad comprende un conjunto de requisitos mínimos para proteger los datos de cuenta,
pudiendo ser ampliado su alcance mediante controles adicionales. Por tanto, es compatible con otras normativas
o reglas nacionales que lo optimicen.

Otros sectores, como la medicina, deben cumplir con marcos de referencia análogos como HIPAA. Otros
importantes incluyen SOX, que aplica  globalmente en EEUU, FISMA, etcétera.

Ámbitos de aplicación

Este estándar aplica a cualquier entidad (pública o privada) que almacena, procesa o transmite CHD: bancos,
comercios, procesadores de pago (pasarelas), proveedores de servicios.

Los requisitos de seguridad de PCI-DSS aplican a todos los componentes de sistemas incluidos y/o conectados
al entorno de datos del titular (CDE – Cardholder data environment).

Relacionado – Herramientas para ayudarte a cumplir con el estándar PCI

El CDE está compuesto por personas, procesos y tecnologías que almacenan, procesan o transmiten CHD SAD.

Categorías del estándar PCI DSS

PCI DSS define dos categorías de datos de cuentas de pago:

  Cardholder data (CHD): los datos del titular de tarjetas incluyen el PAN (Primary Account Number o número
principal de cuenta), el nombre del titular, fecha de expiración y código de servicio.
 Sensitive Account Data (SAD): los datos de autenticación sensibles incluyen el registro total de datos (en banda
magnética o más recientemente, en chip), el código de seguridad de la tarjeta (CAV2/CVC2/CVV2/CID) y los
números de identificación personal (PIN) usados para completar las transacciones.

Normativa de cumplimiento para PCI DSS

Referido a secas como “PCI” de manera mas coloquial, este marco recoge 12 puntos principales para garantizar
el cumplimiento de 6 controles de seguridad diferentes.

Actualmente en su versión 3.2.1, el marco es revisado y actualizado constantemente para recoger nuevos
requisitos o aplicar nuevos estándares de seguridad.

OBJETIVO REQUISITOS

1. Instalar y administrar la configuración de

cortafuegos para proteger datos de los titulares
de tarjetas
Construir y mantener una red y sistemas seguros
2. No emplear credenciales y otros parámetros
de seguridad predefinidos, suministrados por
fabricantes

 
 

3. Proteger la información del titular

almacenada
Proteger los datos del titular
4. Emplear comunicación cifrada al transmitir
datos del titular sobre redes abiertas o públicas.

 
 

5. Proteger todos los sistemas frente al

malware, actualizando la protección empleada
Mantener un programa de getión de regularmente
vulnerabilidades
6. Desarrollar y gestionar sistemas y
aplicaciones seguros

 
Implementar medidas robustas de control de  
acceso
7. Restringir acceso a los datos de titular al
mínimo necesario para su gestión

8. Identifdentificar y autenticar los accesos a

 componentes del sistema

9. Restringir  el acceso físico a los datos de

titulares

 
 

10. Mantener seguimiento y monitorizar todo

Monitorizar y poner a prueba las redes acceso a recursos de red y datos de titulares
regularmente
11. Realizar test de intrusión y seguridad a los
sistemas y procesos regularmente

 
 

Mantener una política de Seguridad de la 12. Mantener una política que regule la
Información seguridad de la información para todo el
personal

Más información

Existen rios de tinta en la red sobre PCI DSS con mayor detalle, seguramente si nunca has oído hablar de ello
ahora mismo estés saturado con tantas siglas y posiblemente no estés seguro de cómo cumplir todos estos
controles (aquí hemos visto un resumen, pero implican bastantes cosas y decisiones particulares).

Por eso te dejo un par de recursos proporcionados por el Security Standards Council, que es quien diseña dicho
documento. Especialmente útil resulta lo siguiente:
20 controles adicionales para optimizar los niveles de seguridad provistos por PCI DSS
Desde el 2006, el PCI SSC ha realizado un trabajo muy importante en cuanto a la estandarización de controles de
seguridad para la protección de datos de tarjetas de pago. Sin embargo, esta labor es una carrera contra el tiempo: cada
día aparecen nuevas vulnerabilidades y los controles de seguridad se quedan cortos si no se actualizan para
gestionarlas. Prueba de ello fue la publicación adelantada (fuera del ciclo tradicional de 3 años ) de la versión 3.1 de PCI
DSS en abril de 2015 para cubrir los problemas derivados de la masificación en la explotación de las vulnerabilidades
CVE-2014-0160 (HEARTBLEED) y CVE-2014-3566 (POODLE).

Por otro lado, el impacto que implica un cambio en el estándar PCI DSS al agregar un nuevo control o
modificar uno ya existente, deriva en inversión de tiempo y dinero en comercios y proveedores de servicio
afectados, lo cual añade una capa adicional de complejidad para lograr que exista una protección efectiva en un
corto plazo. Es por ello que cada cambio viene acompañado de un periodo de gracia para permitir la alineación
del entorno con este nuevo cambio, tiempo que – a la larga – es una ventana de exposición en la cual se debe
asumir el potencial riesgo al que esté expuesta la organización mientras que la aplicabilidad del control entra en
vigencia.

Siendo así, son múltiples las variables que se deben tener en cuenta en el momento de actualizar estos
estándares: complejidad técnica o física del nuevo control, impacto en la operación, cobertura generalista de los
entornos afectados, compatibilidad con las plataformas de hardware y software, cambios en la cultura y el día a
día del mantenimiento de los controles del estándar, resistencia al cambio por parte de las entidades afectadas,
costes vinculados, etc.

Más allá de la seguridad provista actualmente en los entornos certificados en PCI DSS y sin ánimo de
desmeritar el gran esfuerzo que el PCI SSC ha realizado todos estos años, a continuación se enumeran 20
controles de seguridad adicionales que minimizarían aún más el riesgo residual posterior a una implementación
correcta del estándar. Esta lista ha sido elaborada con la experiencia de años de despliegue y auditoría de
múltiples entornos de PCI DSS y se ofrecen como una guía de recomendaciones para aquellas empresas que
quieren optimizar sus niveles de seguridad más allá de los estipulados en el estándar o incluso quieran emplear
estos controles adicionales como parte de sus controles compensatorios en el caso de requerirlos.

1. Búsqueda periódica de datos de tarjeta de pago almacenados en texto claro en medios de

almacenamiento

Uno de los objetivos principales de PCI DSS es la protección de los datos almacenados, gestionado en el
requisito 3. Sin embargo, el estándar carece de un control que permita validar la efectividad de
implementación de dichos controles, lo cual es una verdadera lástima ya que se permitiría la
identificación preventiva y la activación de acciones correctivas del potencial problema, evitando la
exposición a una exfiltración no controlada.

En este caso, la idea sería que existiera un control que exigiera ejecutar de forma periódica una
búsqueda de datos de tarjetas de pago que puedan estar almacenados de forma insegura en los medios de
almacenamiento del entorno. En caso de identificarse alguno, significaría que los controles desplegados
no son suficientes o no se encuentran correctamente implementados.

A pesar de que este control no se encuentra en el estándar PCI DSS, sí que se encuentra en el Anexo A3:
“Validación suplementaria de las entidades designadas (DES)”, solamente requerido para aquellas
entidades designadas por una marca de pago o adquirente a la que le exigen una validación adicional de
los requisitos de PCI DSS existentes.
2. Uso de soluciones de prevención de pérdida de datos (“Data Loss Prevention” - DLP) para
minimizar la exfiltración de datos por canales no autorizados

Las soluciones de prevención de pérdida de datos permiten la monitorización, detección y bloqueo de

información confidencial almacenada, procesada y/o transmitida, permitiendo controlar una potencial
exfiltración causada por errores no intencionales o por acciones intencionales maliciosas. Este software
se puede instalar a nivel perimetral o en estaciones de trabajo y servidores (“endpoint”).

Con una instalación de solución de este estilo se reforzarían los controles procedimentales descritos en
el req. 4.2 para evitar el envío de PAN no cifrados por medios de mensajería de usuario final (correo
electrónico, mensajería instantánea, etc.) y el req. 12.3.10 para evitar que personal que tiene acceso
remoto al entorno pueda copiar, mover y/o almacenar los datos del titular de la tarjeta en unidades de
disco locales y/o en dispositivos electrónicos extraíbles y permitiría la identificación temprana de datos
de tarjeta en canales no autorizados.
3. Integración con otros estándares como PA y PTS (POI/HSM) para que los activos afectados
dentro del alcance estén obligatoriamente certificados

El PCI SSC ha publicado una serie de estándares adicionales a PCI DSS para cubrir otros elementos
potencialmente susceptibles a incidentes con datos de tarjetas de pago:
o PA DSS (Payment Application Data Security Standard), para aplicaciones de pago desarrolladas
y licenciadas por terceros
o PCI PTS (PIN Transaction Security) – POI (Point of Interaction), para la protección de datos de
tarjetas en dispositivos de punto de interacción
o PCI PTS (PIN Transaction Security) – PIN, para la protección del número de identificación
personal (Personal Identification Number – PIN)
o PCI HSM, para definir controles lógicos y físicos de seguridad para módulos de seguridad de
hardware (Hardware Security Module – HSM), empleados para la protección de claves y
procesos de encriptación.

Cada uno de estos estándares es certificable para el elemento afectado.

 No obstante, al día de hoy no se exige explícitamente en el estándar PCI DSS que si dentro de un
entorno existen terminales de pago (datafonos), dispositivos HSM o aplicaciones de pago de terceros,
éstos tengan que estar certificados u homologados, lo cual desvirtúa de cierta manera la existencia de
ese ecosistema de estándares.

En términos ideales, cualquier componente que pueda ser afectado por un estándar del PCI SSC y que
esté presente en un entorno de PCI DSS debería estar certificado u homologado para garantizar su
correcta integración y el mantenimiento con los mismos niveles de riesgo de forma trasversal. El solo
hecho de permitir la interacción con un componente ajeno a estos estándares puede abrir una brecha en
la seguridad del entorno, implicando mayor esfuerzo por parte del comercio o proveedor de servicios
afectado para mantener un nivel de riesgo aceptable. 

4. Requerir escaneo antimalware a nivel perimetral

El requerimiento 5 de PCI DSS exige que se implemente un software antimalware en todos los sistemas
que se puedan ver afectados por software malicioso. Esto quiere decir que el control antimalware se
realizará en el potencial elemento afectado. Sin embargo, este es un control tardío.

En el mercado existen soluciones que permiten implementar las mismas técnicas antimalware en tráfico
HTTP, SMTP, FTP e inclusive integrar las firmas y patrones heurísticos para la monitorización de
tráfico de red como complemento a los sistemas de detección y prevención de intrusiones (IDS/IPS)
descritos en el req. 11.4. Si esto se implementa, se lograría detectar y bloquear el software malicioso
antes de que llegue a las estaciones de trabajo y/o servidores, complementando la seguridad antimalware
en términos generales.
5. Complementar los controles antimalware a nivel de sistema operativo agregando nuevas
funcionalidades tales como DEP, ASRL, etc.

A pesar de que muy seguramente este punto puede ser cubierto por la implementación correcta del req.
2.2 en el proceso de configuración segura de sistemas operativos, estaría muy bien que PCI DSS
exigiera el despliegue de controles de seguridad adicionales, tales como Data Execution Prevention
(DEP), Address Space Layout Randomization (ASLR) y Structured Exception Handling Overwrite
Protection (SEHOP), entre otros, dentro de las actividades de securización de plataformas operativas.

De esta manera se complementaría la seguridad provista por la protección antimalware con

configuraciones adicionales a nivel de sistema operativo para prevenir ataques de desbordamiento de
buffer (buffer overflow) y ejecución de código arbitrario empleados por exploits.
6. Definición de controles de protección en redes virtuales y/o definidas por software (SDN)

El requisito 1 de PCI DSS describe los controles a ser implementados para la protección del entorno de
red, haciendo énfasis en el uso de firewalls y enrutadores. Sin embargo, este requisito está muy
orientado a su implementación en redes y arquitecturas tradicionales.

Sin embargo, con la llegada de la virtualización, los equipos activos de red también han sido afectados,
siendo remplazados por sus contrapartes virtuales (virtual switch, virtual firewall, etc.), tecnologías que
suelen ser olvidadas en el proceso de despliegue de controles de PCI DSS al no estar citadas de forma
explícita.

Siendo así, una revisión del requisito 1 complementándolo con acciones de securización de elementos
de red virtualizados sería una muy buena opción y alinearía dichos controles con estas tecnologías.
7. Requerir de soluciones de filtrado de paquetes a nivel de host

Siguiendo con el requisito 1, PCI DSS establece controles de filtrado a nivel de red entre diferentes
segmentos. Solamente se exige un filtrado de paquetes a nivel de host (firewall personal) en aquellas
estaciones que se conectan de forma remota al entorno (req. 1.4).
 No obstante, una muy buena alternativa para complementar la seguridad de filtrado a nivel perimetral
sería la de requerir el despliegue de una solución de filtrado de paquetes a nivel de host. De esta forma,
se reforzarían los controles de securización del requisito 2.2.2 en servicios, protocolos y daemons y se
limitaría el potencial impacto en el caso de un error en las reglas de filtrado perimetral revisadas
únicamente cada seis meses (req. 1.1.7), aplicando el concepto de defensa en profundidad. 
8. Requerir cifrado a nivel de canal dentro del entorno de cumplimiento

Uno de los controles más controvertidos de PCI DSS es el del cifrado de los canales de comunicación
dentro del entorno de cumplimiento. Solamente se exige en el caso de acceso administrativo que no sea
de consola (req. 2.3), permitiendo que tráfico que pueda contener datos de tarjetas de pago pueda ser
transmitido sin cifrar dentro del entorno.

La implementación del cifrado de comunicaciones dentro del entorno permitiría que toda la
comunicación interna fuese punto a punto, eliminando potenciales riesgos derivados de la interceptación
no autorizada de tráfico y previniendo que los equipos activos de red a nivel interno tengan acceso a los
datos en claro evitando su almacenamiento en ficheros de log, depuración, etc. Esto se puede lograr de
una manera muy fácil empleando los componentes nativos de IPSEC en sistemas operativos, empleando
los controles de cifrado de tráfico de las propias aplicaciones (bases de datos, por ejemplo) o a través de
técnicas de tunelización de tráfico vía TLS o SSH, por ejemplo. El impacto sería mínimo y la ganancia
en términos de seguridad sería tangible inmediatamente.

9. Definir controles para la gestión de nombres de dominio (DNS) tanto a nivel externo como interno

Uno de los elementos “huérfanos” en PCI DSS es el sistema de resolución de nombres (Domain Name
System – DNS). Lo ideal sería que existiese un control específico - al igual que sucede con la
sincronización de tiempo descrita en el req. 10.4 - en el cual se describan los controles que se deben
aplicar a este servicio en un entorno PCI DSS, incluyendo la definición de un servidor DNS central
interno, la gestión de consultas con DNS raíz externos “confiables” y las consideraciones de seguridad
adicionales (como DNSSEC) que podrían desplegarse para robustecer la seguridad de este servicio y
evitar ataques de tipo “pharming”.

Actualmente, este servicio estaría cubierto de forma general por el req. 2, aunque – como se puede ver –
la necesidad de un control específico estaría más que justificada.

Igualmente, tampoco se especifican controles de seguridad de resolución de nombres a nivel externo.

Por ejemplo: Una empresa de comercio electrónico que cuenta con un sitio web y ha registrado un
dominio a su nombre. Ese dominio (que directamente redirecciona todo el tráfico de la transacción de
un cliente a una dirección IP en particular) puede estar registrado en una empresa (registrador de
dominios) con un nivel de seguridad deficiente, con lo cual un atacante no tendría que vulnerar los
sistemas del entorno PCI DSS sino simplemente focalizarse en atacar a ese proveedor, cambiar el
registro DNS a otra dirección IP bajo su control y hacerse a todo el tráfico de tarjetas de ese comercio
electrónico. Es por ello que al igual que otros proveedores de servicio, los proveedores de registro de
nombres de dominio deberían cumplir y estar certificados por PCI DSS para garantizar una seguridad en
toda la cadena transaccional.
10. Establecer controles de seguridad para DHCP

Otro “huérfano” en términos de controles de PCI DSS es el servicio de configuración dinámica de host
(Dynamic Host Configuration Protocol – DHCP). Al igual que como se sucede con NTP y como se
justificó con DNS, en el caso que se emplee DHCP en la red de PCI DSS se deberían establecer los
patrones de configuración y sus limitaciones de ámbito para evitar que equipos no autorizados puedan
obtener toda la información de direccionamiento y enrutamiento del entorno al conectarse.

Igualmente, estaría cubierto actualmente por el req. 2 pero un control específico no estaría mal.
11. Definir controles para la gestión de certificados digitales empleados en comunicaciones HTTPS (y
otros elementos en los cuales pudieran usarse)

El requerimiento 4 de PCI DSS establece la necesidad de asegurar los canales de comunicación con
redes públicas abiertas, exigiendo que si se usa TLS los certificados digitales empleados sean “de
confianza”.

Sin embargo, no se cuenta con ningún control para la protección de dichos certificados. No se indica
cómo se deben almacenar, si deben ser protegidos con un passphrase, los roles y responsabilidades de
quienes puedan gestionarlos, los controles en su ciclo de vida, etc. Es decir: se cuenta con controles para
garantizar la seguridad del tráfico empleando certificados digitales, pero no del proceso para
implementar dicha securización.

Por otro lado, si se emplean certificados digitales en otros flujos dentro del entorno PCI DSS, tampoco
se indica cómo se gestionarán, lo cual puede exponer a la organización a un potencial problema al no
estar formalizado este proceso.
12. Controles adicionales a estaciones con conexión remota y uso de servidores de salto

Las estaciones que cuentan con acceso remoto al entorno de PCI DSS deben cumplir con varios
controles: Tener un firewall personal (req. 1.4) y usar autenticación multifactor (req. 8.3). Sin embargo,
no se indica cómo se puede garantizar que la estación que se conecta cumpla con los niveles de
seguridad del entorno en términos de actualizaciones de seguridad, actualización de patrones antivirus,
controles de acceso, etc. exponiendo al entorno a que, si una estación remota está infectada o
comprometida, dicho compromiso podría ampliarse al resto del entorno si la conexión se autoriza. Esto
aplica no solamente a ordenadores sino también a dispositivos móviles que se permitan en el entorno.

De acuerdo con esto, una estrategia sería el uso de control de acceso a la red (Network Access Control –
NAC). Mediante la implementación de una tecnología de estas características se permitiría garantizar
que los equipos que se conecten cumplan con las políticas del resto del entorno, estén actualizadas y que
la estación en sí sea autenticada. Si no, la estación afectada se aísla o se limita su conexión hasta que no
esté alineada con los requerimientos de la red.

Igualmente, se debería requerir de forma obligatoria el uso de un servidor bastión o de salto (jump
station) para conexiones remotas administrativas. Este servidor recibiría y centralizaría todo este tráfico
hacia el entorno de cumplimiento, evitando exponer las diferentes consolas administrativas, registrando
con detalle todos los saltos a equipos internos y aplicando controles de acceso puntuales posteriores a la
autenticación del usuario.
13. Requerir obligatoriamente el uso de salts en operaciones de hash para la protección de datos de
tarjeta de pago almacenados

Ya es bien sabido por todo el personal de seguridad de la información que uno de los principales ataques
contra las funciones hash es el uso de “tablas arcoíris” (rainbow tables), que permiten identificar el dato
que generó determinado hash mediante la comparación con tablas de valores precomputados. Teniendo
presente que el formato del PAN es conocido de antemano (entre 13 y 16 dígitos con los 6 primeros
dígitos en claro (BIN/IIN) y el último dígito determinista), cuesta muy poco esfuerzo con la capacidad
de cómputo actual generar una tabla precomputada para tales valores. Con este riesgo en mente, se hace
obligatorio el uso de valores de tipo salt (valor pseudoaleatorio que se concatena al dato a proteger antes
de obtener su hash) que compliquen aún más la obtención de un PAN desde su hash si se emplea esta
técnica para la protección de los datos almacenados (req. 3.4).

Actualmente, el uso de salts es solamente una recomendación y su uso es discrecional.

14. Complementar los controles de diagramas de red requiriendo la descripción de direcciones IP /
hostnames
 Los requisitos 1.1.2 y 1.1.3 de PCI DSS especifican la necesidad de mantener un diagrama de red y un
diagrama de flujo actualizados. Sin embargo, no se exige mayor detalle en estos diagramas, lo cual
puede dejar incompleto el objetivo de los requisitos, que es el de identificar de forma clara la ubicación
de los componentes del entorno.

Si dichos requisitos se complementan exigiendo el detalle de direccionamiento IP y hostnames, el

entendimiento y comprensión de los diagramas será más fácil y se podrá integrar de una forma más
sencilla con el inventario de activos del requisito 2.4.
15. Complementar el detalle requerido en el inventario de activos del entorno

El requisito 2.4 pide mantener un inventario de activos del entorno. Sin embargo, no entra en mayor
detalle de lo que debe contener más allá del hardware y software y una descripción de la función/uso de
cada componente. Como tal, este requisito se queda corto en la cantidad de información y la utilidad que
proporciona.

Una alternativa sería exigir una “Cardholder Data Matrix” (CHDM) en toda regla.  El concepto de
CHDM va mucho más allá de un simple listado y permite centralizar en un único documento toda la
información de los activos del entorno, proporcionando una visión completa del alcance.

Esta CHDM debería contener la siguiente información detallada (que de por sí ya se requiere en
diferentes partes del estándar):
o Personal vinculado con el entorno
o Aplicaciones
o Servidores y estaciones de trabajo
o Equipos de red y seguridad perimetral
o Soportes (CD, papel, etc.)- Req. 9.7.1
o Canales de comunicación y redes
o Instalaciones físicas
o Listado de terceros (Proveedores) – Req. 12.8.1
o Ubicación datos PCI DSS – Req. 3.1
o Claves de cifrado – Req. 3.5.1 (actualmente sólo requerido para proveedores de servicio)
o Documentación
16. Protección a nivel de memoria física, virtual y swap

El gran talón de Aquiles de las técnicas de criptografía simétrica y asimétrica es el uso de memoria
intermedia para el almacenamiento temporal de claves, datos a encriptar en claro, contraseñas,
passphrases, etc. mientras que se realizan las operaciones de encriptación y desencriptación. El
requerimiento 3 de PCI DSS describe los controles de encriptación en el almacenamiento de datos,
mientras que el requerimiento 4 hace lo propio con los controles en la transmisión de datos.

Si se parte de la premisa que PCI DSS se debe aplicar en el almacenamiento, transmisión y

procesamiento de datos, ¿qué pasa con los controles orientados a la protección de los datos en memoria
intermedia (RAM, memoria virtual y swap), empleada en el procesamiento? A hoy, no hay ninguna
referencia en el estándar. No obstante, existe una FAQ (1042)  que habla de ello:

“.. If the cardholder data is stored in non-persistent memory (e.g. RAM), encryption of
cardholder data is not required. However, proper controls must be in place to ensure that
memory maintains a non-persistent state. For example, if the memory is being written to a file,
then appropriate PCI DSS requirements are applicable to that file. Where appropriate, this data
should be securely purged as soon as possible - for example, from swap files and temporary
folders…”
 Actualmente, existen diferentes herramientas nativas en la gran mayoría de sistemas operativos que
permiten realizar encriptación de las áreas de paginación (swap) y de ficheros de
hibernación/suspensión, así como controles de acceso restrictivos a nivel de memoria RAM para
prevenir volcados de la misma y ataques con malware del tipo “RAM scraping” , que deberían ser
contemplados en el estándar.

17. Requerir una formación específica para operadores y administradores de la plataforma

El requisito 12.6 de PCI DSS exige una formación general de concienciación sobre seguridad en el
momento de la contratación y por lo menos de forma anual para los empleados del entorno. Yendo más
allá, el requisito 6.5 pide una formación específica anual para desarrolladores y el requisito 12.10.4 para
el personal vinculado al proceso de respuesta a incidentes. Siendo así, ¿por qué no exigir una formación
específica en PCI DSS para operadores y administradores de la plataforma? Para este personal, no es
suficiente una formación general, es indispensable una formación focalizada que permita garantizar que
existe un conocimiento pleno del estándar en las labores del día a día.
18. Definición de controles para la gestión de autenticación de aplicaciones

El requisito 8 de PCI DSS contiene una serie de controles para la gestión del proceso de autenticación
de usuarios interactivos (es decir: que tienen a un humano por detrás). Sin embargo, ¿cómo se debe
proceder con las cuentas de aplicación (aquellas cuentas que permiten que dos o más aplicaciones se
autentiquen mutuamente sin interacción humana)? La ausencia de un control específico para la gestión
de este tipo de cuentas – que por lo general cuentan con altos privilegios - podría permitir que un
potencial atacante acceda de forma no autorizada al entorno, ya que sus niveles de seguridad no suelen
ser tan robustos como en cuentas interactivas.

En este caso, se requeriría definir una persona o rol responsable de esas cuentas, establecer controles de
seguridad apropiados a las mismas (teniendo presente que si se usan contraseñas éstas no se pueden
cambiar de forma periódica, que no se puede agregar autenticación multifactor, que un bloqueo de esta
cuenta por accesos erróneos puede implicar una parada crítica en la operación del entorno, que la
credencial de autenticación debe estar almacenada y disponible en algún lugar por la aplicación y que no
se puede cambiar después del primer uso) y hacerles seguimiento de forma continua.
19. Nombramiento de un responsable de PCI DSS en la organización

La implementación y mantenimiento de PCI DSS en una empresa es un proyecto en sí, con sus
restricciones en términos de tiempo, alcance y costes. Además, se trata de un proyecto trasversal a las
áreas afectadas, que requiere para su correcta gestión un responsable que asuma el cargo de similar al de
un gestor de proyecto (“Project Manager”).

Los requisitos 12.4 y 12.5 requieren la asignación de responsabilidades para ciertas acciones (políticas,
monitorización de alertas, respuesta a incidentes, gestión de cuentas y acceso a datos). Sin embargo, la
asignación de un rol para la gestión general de PCI DSS solamente se exige a proveedores de servicio
(req. 12.4.1) y a entidades designadas (A3.1.1).

En este caso, la idea sería que el mismo requisito cubriera también a los comercios, lo que permitiría
que estas entidades contaran con un responsable de PCI DSS a nivel general, el cual velaría por el
soporte de la Dirección y el seguimiento general del cumplimiento del estándar.

20. Alineación de PCI DSS con otras normativas de protección de datos de carácter personal

De acuerdo con la ISO/IEC 29100:2011 (Information technology -- Security techniques -- Privacy

framework), el Número Primario de Cuenta (PAN – Primary Account Number) se puede catalogar como
Información de Identificación Personal (PII – Personally Identifiable Information), ya que se trata de un
identificador que se puede relacionar con una persona natural. De acuerdo con ello, se deberían generar
políticas orientadas al usuario final (al titular de tarjeta) para que cuente con toda la información
 necesaria para ejercer control sobre sus propios datos, delegados al comercio o al proveedor de servicio
para la ejecución de la transacción.

Figura 2. Principios de protección de privacidad de ISO/IEC 29100:2011

Este nuevo conjunto de controles entraría a complementar los acuerdos contractuales de la organización con sus
proveedores de servicio (req. 12.8.2) y de los proveedores con sus clientes (req. 12.9), agregando
responsabilidades entre la entidad y los titulares de tarjetas.

Conclusión
El estándar PCI DSS (en su versión 3.2 en el momento de la publicación de este artículo) ha permitido que los
comercios y los proveedores de servicio que hacen uso de datos de tarjetas de pago puedan gestionar de una
forma tolerable el riesgo derivado del almacenamiento, procesamiento y transmisión de esta información. Al
tener que ser implementado en diferentes entornos tecnológicos y arquitecturas, la definición y redacción de sus
controles ha sido bastante generalista, lo cual implica que el riesgo residual puede llegar a ser bastante
significativo en función del escenario en el que se aplique.

Para complementar los controles “base” incluidos en PCI DSS se pueden usar controles adicionales como los
descritos en este artículo. Si bien se trata de meras recomendaciones, si se incluyeran dentro de PCI DSS harían
de este estándar una versión “con esteroides”.

Obviamente, la lista de estos controles adicionales no es exhaustiva, ya que la seguridad no es perfecta y

siempre habrá cabida a mejoras. Siendo así, ¿se te ocurren otros controles que puedan mejorar los niveles de
seguridad provistos por PCI DSS?
TEST DE RIESGO
 
1. SI NO
¿Está completamente seguro que no almacena Datos confidenciales de autenticación  
  (incluido el contenido completo de bandas magnéticas, códigos y valores de validación
de tarjetas y bloqueos de PIN)?
 
2. SI NO
¿Se encuentra limitado el acceso a los componentes del sistema y a los datos de los  
  titulares de tarjetas, a aquellas personas que por razon de su trabajo requieren de este
privilegio?
 
SI NO
3.  
¿Se cambian siempre los valores predeterminados de los proveedores de software antes
de instalar un sistema en la red?
 
SI NO
4.  
¿Se han desarrollado estándares de configuración para todos los componentes del
sistema?
 
5. SI NO
¿Se han desarrollado todas las aplicaciones web (internas y externas, que incluyan  
  acceso administrativo web a la aplicación) según las directrices de codificación segura,
como la Guía para proyectos de seguridad de aplicaciones web abierta?
 
SI NO
6.  
¿Todos los componentes de sistemas y software cuentan con los parches de seguridad
más recientes instalados por los proveedores?
 
7. SI NO
¿Existe algún proceso para vincular todos los accesos a componentes del sistema  
  (especialmente el acceso con privilegios administrativos, tales como los de raíz) a cada
usuario en particular?
 
SI NO
8.  
¿Se revisan los registros de todos los componentes del sistema al menos una vez al
día?
 
9.
¿La configuración del firewall prohíbe el acceso directo público entre Internet y todo
componente del sistema en el entorno de datos de los titulares de tarjetas?
CredibanCo, sigue consolidándose como la red de
pagos más segura del país

La seguridad y confianza ha sido el principal obstáculo para la erradicación del efectivo en Colombia y por
consiguiente de la masificación de los pagos electrónicos en el país. Por esta razón CredibanCo estableció como
uno de sus pilares la gestión de la seguridad de los procesos y clientes.

En el año 2006 se logró la certificación PCI DSS la cual en diciembre de 2018 obtuvo la recertificación y
versión actualizada PCI DSS 3.2.1. Esta distinción es otorgada a las organizaciones que procesan, almacenan
y/o transmiten datos de tarjeta habientes que, a su vez cumplen con los rigurosos estándares de seguridad
encaminados a proteger los datos y así evitar el fraude que afecta a los titulares de las tarjetas y entidades
bancarias.

Los compradores modernos demandan cada vez más, un proceso de transformación tecnológico acelerado que
se adapte a las necesidades basadas en la inmediatez y la seguridad de las transacciones electrónicas. Esta
premisa la ha entendido CredibanCo y es la que ha permitido ha permitido ser la procesadora de pagos
electrónicos más grande del país con más del 50 por ciento de las compras de los colombianos  y  el 94 por
ciento en transacciones online con tarjeta.

“Somos la Red de pagos más segura porque estamos certificados PCI DSS desde el 2006 y en diciembre de
2018 fuimos recertificados en la última versión 3.2.1.. Y somos la única Red que cuenta por segundo periodo
consecutivo con la Certificación PCI Security PIN Versión 2.0 con vigencia a 2021”” afirma Gustavo Leaño,
Presidente de CredibanCo.

En Colombia no existe otra procesadora de pagos electrónicos que cuente con la experiencia de estas dos
certificaciones, las cuales reducen el fraude y mitigan posibles impactos derivados de la pérdida de información
sensible de los tarjetahabientes.

La normativa PCI-DSS acecha a los hoteles, ¿estás

preparado?
¿Has recibido una llamada de tu banco para preguntarte si tu hotel cumple la normativa de seguridad PCI-DSS?
Si es el caso, ya sabrás de qué se trata aunque quizás no sepas aún cómo

cumplirla.  En caso contrario, la recibirás próximamente. Este artículo te

interesará para saber de qué se trata y cómo anticiparte.

¿Qué es PCI-DSS? ¿afecta a mi hotel?

Es un estándar de seguridad que afecta a los entornos donde se trabaja o almacenan tarjetas de crédito. Algo que
afecta directamente a cualquier hotel.

No es más que un “manual de buenas prácticas” que toda empresa afectada debe seguir. PCI-DSS viene
de Payment Card Industry Data Security Standard y fue creado por un consorcio de tarjetas de crédito que
incluye a Visa, Mastercard y American Express, entre otras.

¿Qué busca PCI?

Evitar o minimizar los muchísimos fraudes de tarjetas de crédito que existen, algo que se ha disparado con la
llegada de internet y el e-commerce.

¿Es obligatorio certificarse PCI?

No hay ninguna ley que obligue a su cumplimiento. En cambio, es un requisito esencial para las entidades
emisoras de tarjetas y los propios bancos que podrán reducir sus servicios o romper relaciones contractuales en
caso de no tener la certificación PCI. La amenaza más habitual de los bancos por ahora es retirarte el servicio
de TPV físicos (datáfonos).

¿Por eso me presionan los bancos con la certificación PCI?

Es un efecto dominó. Ante un fraude de tarjeta, las entidades emisoras como Visa miran hacia los bancos, que a
su vez miran al comercio (hotel) que a su vez mira a sus proveedores (empresas de PMS, channel managers,
motor de reservas, etc.).

Hasta ahora el requisito de los bancos al hotel era que todos sus proveedores cumplan la normativa PCI. El
hotel hace bien exigiendo que éstos cumplan (Mirai tiene la certificación PCI-DSS). En cambio, en muy poco
tiempo el requerimiento se ampliará y obligará a tu hotel a cumplir también con la normativa, ¿estás preparado?
¿En qué me afectará el cumplimiento de PCI? ¿cambiará mi día a día?

PCI te obligará a un profundo cambio tecnológico pero también de filosofía. Son varios requisitos que deberás
revisar y adecuar tu operativa en consecuencia. No entramos en detalles porque no es el punto de este post. Sí
en cambio aportamos algunos ejemplos sencillos que ilustran bien el alcance y la filosofía de PCI.

 Usuarios únicos. Cada recepcionista o persona del hotel que tenga acceso o trabaje con datos de tarjetas de
clientes debe tener un usuario único con el fin de poder monitorizar el acceso de manera individual en caso de
un incidente con una tarjeta concreta. Esto implicará tener muchas cuentas nominales en los ordenadores, el
PMS, en la extranet de Booking.com o de Mirai, lo que complica mucho la operativa de recepción, por ejemplo.
 Faxes de confirmación de reservas que llevan la numeración de tarjeta del cliente. Mantener esta forma de
confirmación se complica mucho hasta el punto de hacerla inviable. Se acabó el tener el fax en recepción al
alcance de todo el personal y de los clientes. Deberás mover la máquina de fax a un área con acceso restringido,
con cámaras de seguridad y con registro de cada persona que entra y sale. La importación automática de
reservas en tu PMS será tu gran aliado para resolver este problema.
 CVV2. Este dato está terminantemente prohibido almacenarlo (requisito 3.2 de la norma). Si no lo puedes
guardar y no lo vas a usar en tiempo real, ¿para qué pedirlo? Además no te sirve de nada para transacciones con
el TPV físico y no te ayuda en caso de devoluciones. Mejor no lo pidas a tus clientes a la hora de hacer reservas
(salvo en tarifas con TPV virtual donde el banco sí lo pedirá para ejecutar el cargo) y te quitas el problema.
 Si tienes el PMS en el hotel y almacenas ahí los datos de tarjeta prepárate para un gran cambio. Deberás
adaptar toda tu arquitectura de red para cumplir la normativa: separar el servidor en una red diferente con
control físico de acceso, cámaras de seguridad y registro de entrada y salida. También deberás añadir un
cortafuegos que controle y registre todos los accesos a su vez en un tercer entorno también separado de los dos
primeros. Un follón del que no quieres saber. Mejor apoyarte en tu fabricante de PMS  para buscar la mejor
solución. Desde luego versiones en la nube (cloud) son más recomendables para estos casos porque así no
guardas ninguna tarjeta en tu hotel.
 Formación, documentación y procedimientos. Prepárate para una avalancha de documentos que tendrás que
hacer (lo normal es apoyarse en una consultora externa) pero que luego tendrás que seguir. Te cambiará la
forma de trabajar en todo lo relacionado con el uso y tratamiento de tarjetas. Necesitarás un equipo interno
responsable de que realmente se cumple la normativa. Cada nuevo empleado con acceso a tarjetas requerirá
formación.

Todo esto hasta que lleguemos a un escenario donde todo cobro por parte del hotel o manera de garantizar una
reserva se haga por medios de pago centralizados y externos al hotel (empresas como Google, Apple o Paypal
ya están avanzando en esta línea), eliminando el riesgo de que haya una brecha de seguridad en el propio hotel.

¿Qué tengo que hacer y cuánto cuesta obtener la certificación PCI?

La teoría es larga y farragosa. No vamos a hablar de ella aquí. Tan sólo adelantar que son 12 puntos que van
desde la arquitectura de los sistemas (separación con cortafuegos, encriptación de tarjetas, etc.) hasta los
procedimientos de seguridad y documentación necesaria. Una guía rápida (y ya tiene 40 páginas) la puedes
encontrar aquí. Un trabajo costoso pero, me temo, necesario.

La certificación en sí es gratuita. En cambio, el tiempo y recursos que necesitarás para ello te costará mucho.
Nuestra recomendación es contratar a una de las muchas empresas consultoras y certificadoras PCI (gran
negocio que ha emergido al amparo de esta nueva normativa) e ir de su mano (en muchos casos no será una
opción sino una obligación de hecho).

Te costará un gasto inicial de 10.000€ hasta 60.000€ según el nivel de exigencia que tengas (a mayor volumen
de tarjetas de crédito gestionadas anualmente mayor será el nivel de seguridad requerido). Grandes cadenas de
cientos de hoteles en medio mundo manejan otros costes, claro está. A partir de la certificación inicial deberás
re-certificarte cada año siendo el coste mucho menor porque gran parte del trabajo está hecho.
El plazo también varía pero podría oscilar entre 3 y 12 meses, de nuevo en función del volumen de tarjetas que
manejes.

¿Tener la certificación PCI-DSS garantiza estar exento de fraude?

Lamentablemente no. Cumplir con la PCI-DSS mejora tus sistemas y nivel de seguridad haciendo más difícil
tener un incidente pero no garantiza al 100% que no ocurra. De hecho cada año muchas empresas con la
certificación PCI sufren ataques y robos de tarjetas.

Conclusión

La seguridad y el control del fraude es un intangible cada vez más importante y estar al día en normativa y
buenas prácticas te evitará muchos problemas futuro. Es por tanto una buena inversión. Es normal que como
empresario te cueste destinar recursos a algo que no ves la ganancia monetaria a corto o medio plazo.

En cambio los bancos han empezado a presionar y esto parece ya imparable. Van cayendo fichas del dominó y
tarde o temprano (6 meses? 1 año? 2 años? Nadie sabe … ) llegará la ficha de las cadenas medianas (ya les ha
llegado a las grandes) y luego a los hoteles individuales. Conocer lo que te viene encima es lo menos que
puedes hacer. Anticiparse sería lo perfecto.