PCI-DSS New requirements for Contact Centers, Call Centers and ...
37
www.isaca.org.uy PCI-DSS New requirements for Contact Centers, Call Centers and Mobile Operations compliance Gabriel Croci, CISA, CRISC
Transcript of PCI-DSS New requirements for Contact Centers, Call Centers and ...
www.isaca.org.uy
PCI-DSS
New requirements for Contact
Centers, Call Centers and Mobile
Operations compliance
Gabriel Croci, CISA, CRISC
www.isaca.org.uy
1. PCI – Origen y conceptos principales
2. Información existente en las tarjetas
3. Entorno afectado por PCI DSS
4. Service Provider PCI Levels
5. La norma PCI DSS y sus requisitos
6. Por qué cumplir con PCI DSS?
7. PCI SSC FAQ
8. Nuevas Reglas
9. Otras características
2
ÍNDICE
www.isaca.org.uy
– PCI SSC (Security Standards Council) es el Consejo de Normas de
Seguridad de la Industria de Tarjeta de Pagos, formado en 2006 por:
– Su objetivo es aunar esfuerzos en la asegurar el entorno de seguridad de
las tarjetas de pago, facilitar la adopción de medidas de seguridad
consistentes a nivel mundial y reducir los casos de fraude.
3
PCI – Origen y conceptos principales
www.isaca.org.uy
– Para ello han creado varios estándares y mecanismos de certificación:
4
PCI – Origen y conceptos principales
www.isaca.org.uy
PCI DSS – Data Security Standard
– PCI DSS se aplica a todas las entidades que participan en los procesos
de las tarjetas de pago (comerciantes, instituciones financieras,
entidades adquirentes, entidades emisoras, proveedores de servicios…)
y en general, a toda organización que almacene, procese o transmita
datos de cuentas, siendo el número de cuenta (PAN) el factor que
determina la aplicabilidad.
PCI PA-DSS – Payment Application
– PA-DSS se aplican a proveedores de software y demás que desarrollan
aplicaciones de pago que almacenan, procesan o transmiten datos de
titulares de tarjetas.
– Aplica siempre que dichas aplicaciones se vendan, distribuyan u
otorguen bajo licencia a terceros.
– Los comercios y proveedores de servicios deberían utilizar únicamente
aplicaciones que cumplen con PA-DSS.
5
PCI DSS - PCI PA-DSS
www.isaca.org.uy
PCI PTS (anterior PCI PED)
• Define un conjunto de requisitos de seguridad orientados a las características y mecanismos de gestión de los dispositivos utilizados para la protección de los PIN de las tarjetas, así como otras actividades relacionadas con el procesamiento de pagos.
• Los requisitos son para los fabricantes en el ámbito del diseño, fabricación y transporte de los dispositivos hasta las entidades que los utilizan.
• Requisitos de seguridad disponibles:
– POI Modular Security Requirements v3.0
– Encrypting PIN Pad Devices v2.1
– Point of Sale Devices v2.1
– Hardware Security Module (HSM) v1.0
– Unattended Payment Terminals (UPT) v1.0
6
PCI PTS – PIN Transaction Security
www.isaca.org.uy
7
Información existente en las tarjetas
www.isaca.org.uy
8
Información existente en las tarjetas
Campos de la pista 1
www.isaca.org.uy
9
Información existente en las tarjetas
Campos de la pista 1
www.isaca.org.uy
• PCI DSS afecta a todo aquel que almacene, procese y/o transmita datos de
cuentas, siendo el número de cuenta (PAN) el factor que determina la
aplicabilidad
• Los requisitos de las PCI DSS aplican a todos los componentes del sistema.
• Entendemos por “componente” como cualquier elemento de red, servidor o
aplicación incluida en el entorno de los datos de tarjetas o que esté conectado
a éste.
• El entorno de los datos de tarjetas consta de personas, procesos y tecnología
que almacenan, procesan o transmiten datos de tarjetas o datos
confidenciales de autenticación. Sin una adecuada segmentación de red,
todos los elementos conectados a los componentes donde se procesen,
transmitan o almacenen datos de tarjeta, estarían afectados por PCI DSS.
10
Entorno afectado por PCI DSS
www.isaca.org.uy
11
Entorno afectado por PCI DSS
www.isaca.org.uy
• Al igual que comercios y proveedores de servicios, tienen que proteger el
entorno donde almacenen, procesen o transmitan datos de cuentas, siendo el
número de cuenta (PAN) el factor que determina la aplicabilidad.
• Pero además, pueden ser ENTIDADES ADQUIRIENTES, siendo como tal
responsables del cumplimiento de los comercios y proveedores, por lo que
deben:
• Garantizar que los comercios entienden los requerimientos de PCI DSS.
• Realizar un seguimiento del cumplimiento en cada comercio.
• Gestionar las comunicaciones con los comercios.
• Trabajar con los comercios hasta que consigan la validación de PCI DSS.
• Informar del estado de cumplimiento de los comercios a las marcas de tarjetas.
• Responder ante responsabilidades que resulten del no cumplimiento de los
programas de las marcas de tarjetas.
12
Entidades financieras
www.isaca.org.uy
13
Esquema básico de funcionamiento:
Actores en el proceso de pago
www.isaca.org.uy
Level 1
• Todos los procesadores de terceros, todos los proveedores de servicios que
almacenan, transmiten o procesan más de 300.000 transacciones anuales
(evaluado por marca de tarjeta)
Requerimientos
– Evaluación anual in situ por un Asesor de Seguridad Calificado
(Certificado)
– Escaneo de red trimestral por un Proveedor Aprobado
Level 2
• Incluye todos los proveedores de servicios que almacenan, transmiten o
procesan menos de 300.000 transacciones al año (evaluada por marca de
tarjeta)
Requerimientos
– Cuestionario Anual de autoevaluación (SAQ) - Versión D
– Escaneo de red trimestral por un Proveedor Aprobado
14
Service Provider PCI Levels and
Requirements Summary Service Provider
www.isaca.org.uy
15
Service Provider PCI Levels and
Requirements Summary Merchants
www.isaca.org.uy
16
Service Provider PCI Levels and
Requirements Summary Service Provider
www.isaca.org.uy
17
Restricciones sobre el almacenamiento
y requisito de proteger y cifrar (req. 3.4)
www.isaca.org.uy
18
Selección del cuestionario de autoevaluación (SAQ)
www.isaca.org.uy
19
Certificaciones de empresas emitidas por PCI SSC
www.isaca.org.uy
20
Organización del estándar
www.isaca.org.uy
21
Requisitos de PCI DSS v2.
www.isaca.org.uy
22
Aplicación de los requisitos al entorno PCI
www.isaca.org.uy
• La investigación, que involucró una encuesta nacional de directores de Call
Center del Reino Unido en septiembre, que se encuentra a más de 19 en 20
centros de atención telefónica no eliminar o enmascarar la tarjeta de crédito en
sus grabaciones de llamadas, lo cual es una violación directa de la Payment
Card Industry Data Security Standard (PCI DSS).
• De los 133 directores de Call Center contactados por Veritape para la
encuesta, sólo el 3 por ciento están en conformidad con las directrices.
• El resultado, de acuerdo con Veritape, es que 285 millones de transacciones
de tarjetas de crédito o débito en el Reino Unido se puso en peligro el año
pasado.
• Entre las razones para no cumplir con PCI DSS, el 61 por ciento de los
gerentes dijeron que no tenían conocimiento de las normas, el 18 por ciento
eran conscientes, pero dijeron que no podían cumplir, por razones técnicas o
presupuestarias, el 11 por ciento estaba al tanto pero optó por no seguirlas y 6
por ciento eran conscientes y fueron avanzando en el cumplimiento.
(Veritape UK 2009)
23
Compliance Survey
www.isaca.org.uy
• No identificar todos los flujos de datos de tarjeta.
• No tener un inventario completo de todos los sistemas y localizaciones
afectadas por PCI.
• No identificar todas las conexiones de red con el entorno afectado.
• Tener una inadecuada segmentación de la red.
• Falta de apoyo de la Dirección (y presupuesto).
• Olvidar que PCI DSS es un proceso continuo.
24
Errores comunes en la adecuación a PCI DSS
www.isaca.org.uy
• Mantener e incrementar la confianza de los clientes (control del riesgo de
pérdida de imagen).
• Facilita el cumplimiento con la legislación, estándares o requerimientos de
seguridad y privacidad.
• La asociación de entidades que apoyan PCI, así como las entidades
adquirientes, puede imponer pagos, sanciones o incrementos de tarifas
por incumplimiento de PCI, o peor aún, rescindir el servicio de utilización
de las tarjetas.
• Protección ante responsabilidades y costes potenciales vinculados al mal
uso de información de tarjetas de crédito, costes de investigación en caso
de incidente, costes legales, etc…
25
¿Por qué cumplir con PCI DSS?
www.isaca.org.uy
26
Objetivos de Control
www.isaca.org.uy
• 3.2.2 Do not store the card-validation code or value (three-digit or four-digit
number printed on the front or back of a payment card) used to verify Card-not-
present transactions.
The purpose of the card validation code is to protect "card-not-present"
transactions (Internet or mail order/telephone order (MO/TO) transactions), where
the consumer and the card are not present.
These types of transactions can be authenticated as coming from the card owner
only by requesting this card validation code, since the card owner has the card in-
hand and can read the value.
If this prohibited data is stored and subsequently stolen, hackers can execute
fraudulent Internet and MO/TO transactions.
This storage also violates payment brands' regulations and can lead to fines and
penalties.
27
Especificaciones
www.isaca.org.uy
– PCI SSC FAQ están diseñadas para proporcionar a los comerciantes,
asesores, adquirentes y otros interesados del Consejo con una
orientación clara y oportuna sobre las normas PCI.
– Se trata de un importante canal de comunicación dos de manera que el
PCI SSC atrae retroalimentación del mercado y conocimientos valiosos, y
es capaz de compartir esto con la industria.
– El 22 de enero de 2010, como parte de la línea Testimonios FAQ y el
proceso de presentación, el examen periódico de lengua Preguntas
frecuentes y consultas de los organismos participantes en la cooperación
Sur-Sur trató de aclarar su posición respecto a las grabaciones de audio
de llamadas del centro.
28
PCI SSC FAQ
www.isaca.org.uy
• "Es una violación de PCI DSS 3.2 el almacenar todos los datos confidenciales de
autenticación, incluyendo los códigos de validación de tarjetas y valores, previa
autorización aun cuando estén cifrados.
• Por lo tanto, esta prohibida la utilización de cualquier forma de grabación de audio
digital (utilizando formatos como wav, mp3, etc) para almacenar CAV2, CVC2, CVV2 o
CID códigos después de la autorización, ya que los datos de la tarjeta pueden ser
fácilmente extraído por medio de software de libre acceso.
• Con carácter excepcional, el almacenamiento de CAV2, CVC2, CVV2 o CID códigos en
un formato analógico después de la autorización está permitido; ya que estas
grabaciones no pueden ser datos extraídos fácilmente. Sin embargo las protecciones
físicas y lógicas definidas en PCI DSS todavía se debe aplicar a estos formatos de
grabación analógicas de llamada.
• Soluciones de grabación de audio que impiden el almacenamiento o facilitar la
eliminación de CAV2, CVC2, CVV2 o CID códigos y otros datos de tarjeta están
disponibles comercialmente de un número de vendedores. Todos los registros que
contengan datos de titulares de tarjetas capturadas por los Call Center deben ser
protegidos de acuerdo con la norma PCI DSS, incluyendo PCI DSS 3.4. "
29
FAQ #5362
www.isaca.org.uy
– El 22 de enero de 2010, el PCI SSC publicó una actualización de su
aclaración con respecto a sus preguntas más frecuentes sobre el
almacenamiento de los Call Center CVV / CVC / CID en las grabaciones
de sus llamadas.
– La conclusión es que los Call Center ya no se permite para almacenar la
información del titular tal en los registros que se mantienen de forma
digital, sin importar si están cifrados.
30
Nuevas Reglas
www.isaca.org.uy
– Como resultado de la información de mercado adicional, el 17 de febrero
de 2010, el SSC modificado el lenguaje nuevo para aclarar aún más su
posición en las grabaciones de audio.
– Pregunta: ¿El audio / grabaciones de voz que contengan datos de
titulares de tarjetas y / o datos confidenciales de autenticación están
incluidos en el alcance de PCI DSS?
– Esta respuesta tiene por objeto aclarar los Call Center que registran datos
de titulares de tarjetas en grabaciones de audio, y se aplica únicamente al
almacenamiento de códigos de validación de tarjetas y valores
(denominados CAV2, CVC2, CVV2 o CID códigos de las marcas de
pago).
– Es una violación de PCI DSS 3.2 el almacenar todos los datos
confidenciales de autenticación, incluyendo los códigos de validación de
tarjetas y valores, previa autorización aun cuando estén cifrados.
31
Nuevas Reglas
www.isaca.org.uy
– Por lo tanto, esta prohibida la utilización de cualquier forma de grabación
de audio digital (utilizando formatos como wav, mp3, etc) para almacenar
CAV2, CVC2, CVV2 o CID códigos después de la autorización si los
datos se pueden consultar, se reconoce que existen varias herramientas
que podrían consultar una variedad de grabaciones digitales.
– Donde exista la tecnología para evitar la grabación de estos elementos de
información, esta tecnología debe estar habilitado.
– Si estas grabaciones no pueden ser extraídos de datos, almacenamiento
de CAV2, CVC2, CVV2 o CID códigos después de la autorización puede
ser permitido, siempre y cuando la validación correspondiente se ha
realizado. Esto incluye las protecciones físicas y lógicas definidas en las
normas PCI DSS que siguen deben ser aplicadas a estos formatos de
grabación de llamadas.
• .
32
Nuevas Reglas
www.isaca.org.uy
– En un entorno de Call Center donde los operadores están tomando pedidos por
teléfono y aceptar tarjetas de crédito / débito para el pago, hasta que la transacción
de la tarjeta está aprobado o rechazado, estamos hablando de autorización previa
de datos.
– Sólo los datos de los titulares después de la autorización o declinación (también
conocidos como datos posteriores a la autorización) está cubierto por la norma PCI
DSS.
– Sin embargo, las marcas de tarjetas de esperar la autorización previa de datos
para ser protegido con la misma seguridad que los datos posteriores a la
autorización.
– Las PCI DSS puede proporcionar a las organizaciones una guía sobre cómo
proteger los datos de autorización previa, pero pre-autorización no es del ámbito
para el cumplimiento de PCI.
– Mientras que la norma PCI DSS en la actualidad no se refiere a la autorización
previa de datos, el PCI SSC y las marcas de tarjetas han dejado muy claro que la
autorización previa de datos se ha de proteger con el mismo celo que los datos
posteriores a la autorización
33
Otras características:
Autorización Previa
www.isaca.org.uy
• Desde una perspectiva de cumplimiento de PCI, la respuesta es 'no', aunque hay una serie de requisitos de PCI que conducirían a restringir lo que está en el Call Center actual. Sin embargo, la mejor práctica es operar cualquier Call Center de datos potencialmente sensibles en un medio ambiente 'estéril'.
• Eso significa escritorios limpios, sin objetos personales en la estación de trabajo, papel y bolígrafos para no escribir las cosas, encerrados por las estaciones de trabajo y otras restricciones para que la información sensible no se filtre desde el centro de llamadas.
• La idea de crear un ambiente estéril con la prohibición de los teléfonos celulares y dando lockers al personal para asegurar sus objetos personales se ajusta a lo que vemos en los centros de llamadas.
• Además de toda la seguridad física, el personal de los Call Center necesitan ser capacitados en materia de seguridad y privacidad.
• El personal del Call Center deberá firmar un acuerdo que dice que ellos reconocen que estará en contacto con los datos de titulares de tarjetas y que el titular de la tarjeta debe ser protegida de conformidad con las normas PCI DSS y otros requisitos normativos y legales.
34
Otras características:
¿Necesitamos una sala limpia?
www.isaca.org.uy
– El PCI DSS no requiere que el personal del Call Center para manejo de
tarjetas de crédito este separado del resto del personal del Call Center,
pero las buenas prácticas sugieren que es una excelente implementación
la de mantener los diferentes tipos de actividad separados.
– Otra buena práctica es separar los equipos de Call Center que manejan
datos sensibles del personal que no maneja datos sensibles.
35
Otras características :
¿Es necesario separar nuestro equipo responsable
de la toma de información de tarjetas de crédito?
www.isaca.org.uy
• Otra área en la que los Call Center pueden estar en riesgo es la estación de trabajo. La razón es que la estación de trabajo entra en contacto con los datos de titulares de tarjetas. Dependiendo de cómo se utiliza la estación de trabajo y como esta configurada, se determinará el nivel de seguridad que rodea a la estación de trabajo.
• El gran movimiento en el Call Center hoy es el uso de estaciones de trabajo virtuales a través de Citrix, VMware o soluciones similares. En estas situaciones, la estación de trabajo es sólo un dispositivo de visualización. El servidor de la creación de los puestos de trabajo virtuales tiene que ser física y / o lógicamente separados de los otros servidores virtuales.
• La amenaza de una estación de trabajo físico en cualquier ambiente es que un registrador de teclado está instalado para grabar todo lo escrito en la estación de trabajo físico. Como resultado, la estación de trabajo físico tiene que tener su sistema / registros de sucesos supervisados y tienen propiedades anti-virus, anti-malware y control de archivos críticos implementado.
36
Otras características :
Estación de Trabajo
www.isaca.org.uy
• La seguridad de las transacciones realizadas a través de dispositivos móviles constituye un aspecto clave, con independencia de la tecnología utilizada.
• Los expertos señalan que un sistema seguro de pago por móvil debe reunir las siguientes características:
– confidencialidad, de tal manera que la información crítica no pueda ser accedida por una persona, proceso o dispositivo no autorizados;
– integridad, con la finalidad de impedir que ni la información ni los sistemas sean dañados por terceras personas;
– disponibilidad, los usuarios autorizados deben ser capaces de acceder al sistema en cualquier momento;
– autentificación, para evitar el acceso de impostores;
– autorización, verificar que el usuario está autorizado para hacer la transacción solicitada; y
– no-repudio/trazabilidad, en caso de que el usuario negase que la transacción tuvo lugar, el sistema debe proporcionar prueba de que efectivamente el pago se ha llevado a cabo.
37
Otras características:
Elementos de Seguridad de Pago Móvil
