Etiquetado: 

Este debate contiene 9 respuestas, tiene 3 mensajes y lo actualizó David Acosta David Acosta hace 2 meses, 3 semanas.

  • Autor
    Publicaciones
  • #47722
    Avatar
    sturon
    Participante

    Buenos días,

    Antes de nada agradecer sinceramente a David Acosta y al proyecto pcihispano.com , todo lo que están aportando en materia de PCI-DSS.

    Tengo una duda acerca del SAQ de PCI-DSS que se debe completar para este proceso:

    • En la compañia hay operadores que contactan telefónicamente con clientes para ofrecer un servicio.
    • Si en la llamada, el operador vende el servicio al cliente, este puede pagarlo con tarjeta de credito.
    • En ese caso, el cliente proporciona los datos de su tarjeta al operador, y en la misma la llamada el operador se conecta a una plataforma WEB de pago, externa y certificada PCI DSS, introduce los datos DIRECTAMENTE en ella y el pago queda efectuado.
    • La conversación queda grabada en el sistema informatico de la compañía, SALVO el momento de pago por tarjeta de credito, que se pausará/ofuscará automaticamente. Por tanto no se guardan datos de tarjeta de forma electronica.

    Notas:
    – Existe la posibilidad de, en el momento del pago, se pase la llamada a otro operador/entorno «VENTA POR TARJETA» segregado y aislado tanto logica (apps, internet, FireWall, etc.) como fisicamente.
    – En principio NO se plantea posibilitar marcación DTMF o reconocimiento IVR a traves de un tercero (certificado PCI DSS).

    Tras leer https://www.pcihispano.com/todo-lo-que-siempre-ha-querido-saber-acerca-de-los-saq-cuestionarios-de-auto-evaluacion/ , estoy en duda entre el SAQ A y el SAQ C-VT
    ¿cual es la diferencia en mi caso particular? ¿que opináis?

    Un saludo y gracias de antemano.

  • #47726
    David Acosta
    David Acosta
    Participante

    Buenas tardes:

    Gracias por tus comentarios.

    Respecto a tu pregunta, en el artículo «Protección de datos de tarjetas en pagos vía telefónica y grabación de llamadas en Centros de Llamadas (Call Centers)» se discuten algunos puntos que podrían ser interesantes para tu entorno, al igual que en el “Information Supplement: Protecting Telephone-based Payment Card Data”, que, por cierto, este año se actualizará (la versión publicada data de 2011).

    Ahora bien, hay que dividir tu entorno en varios escenarios:

    1) El entorno de los terminalistas y sus ordenadores: Por lo que comentas, debido a que la captura de datos de tarjetas y la autorización se realizan a través de una terminal virtual web, todo apunta a que dicho entorno debería cumplir con un SAQ C-VT.
    2) El entorno de telefonía: Este es un punto muy importante a tener en cuenta. Si la llamada se hace a través de Voz sobre IP, entonces el entorno de red y centralitas estará cubierto por PCI DSS. Revisa por favor el artículo «Aplicación de PCI DSS en plataformas de VoIP (Voz sobre IP)«.
    3) El entorno de grabación de llamadas: Si la llamada se graba y en dicha grabación se almacena el PAN y otros datos de tarjeta, entonces ese entorno tiene que cumplir con PCI DSS. La única forma de excluir este entorno es que los datos de la tarjeta no se graben y esto se tiene que implementar mediante un sistema automático (es decir: el pausado de la llamada no puede ser manual ni gestionado por el terminalista). Si se logra garantizar que en las llamadas no hay datos de tarjetas y que estos no pueden ser «consultables», se podría excluír.

    Si todos los puntos los tienes controlados, sería un SAQ C-VT. Aplicaría un SAQ A únicamente en el caso de que toda la infraestructura (personal, redes, autorización de transacciones, etc.) estuviera delegado en un proveedor que cumpliera con PCI DSS (un call center PCI DSS, por ejemplo).

    Para los otros puntos que comentas:

    • El entorno/operador al que se le redirige la llamada estaría igualmente afectado por PCI DSS. Si dicho proveedor cumpliera con PCI DSS, ese sería un escenario en el cual tú como empresa (que recibes la llamada y la rediriges) debería cumplir con un SAQ A.
    • Si no se usa DTMF o reconocimiento IVR no hay problema. Hay otras muchas opciones de evitar el «contacto directo» con los datos de tarjeta (pausado automático, ocultación de la voz con ruido, etc.) que también son válidas.

    Revisa mis comentarios y si tienes más dudas, con gusto.

  • #47729
    Avatar
    sturon
    Participante

    Muchas gracias David, me ha servido de gran ayuda.

    Conocia el excelente articulo de protección de pagos telefonicos de PCIhispano, pero desconocía el de pci council. Estaré atento a la revisión.

    Efectivamente aplica el SAQ C-VT, pues la compañía no valora externalizar el proceso completo de venta telefónica a un tercero PCI-DSS (SAQ A).

    Lo que no habia reparado es en el asunto VoIP. Importante pues implica alto bastionado, cifrado, segregación, etc. de las redes VoIP, por tanto re-estructuración IT… habrá trabajo.

    Respecto al entorno de grabación, la idea es pausar la grabación en el momento de comunicar los datos, veremos a ver como de automático lo puedo hacer: ¿serviría activar la pausa el cliente por marcación de un codigo (#5 o similar)?
    Los datos en cualquier caso no serán son consultables (no hay reconocimiento ni indexación de la voz en las grabaciones que se guardan).

    Un saludo!

  • #47734
    David Acosta
    David Acosta
    Participante

    Buenas tardes:

    • El tema de VoIP casi nunca se tiene en cuenta y es un error clásico, incluso para QSAs. En este caso, una sugerencia sería emplear encriptación en el canal de voz usando un protocolo seguro (SRTP en vez de RTP), pero todo depende del fabricante de la centralita telefónica (PBX) y de los teléfonos que tengáis.
    • La parte de grabación, si vais a utilizar pausado, debe ser estrictamente automático. Es decir: no debe depender de una acción de una persona para activarse. Las soluciones de software que hacen esto implican el despliegue de un agente en el ordenador de los terminalistas (agentes). Este agente contiene reglas internas que detectan el momento justo en el cual el terminalista ingresa al TPV virtual (o al formulario de captura de datos de tarjeta) y pausa automáticamente la grabación.

    Algunas ideas que te podrían servir:

    • Algunos clientes lo que hacen es tener dos entornos del call center: uno para la recepción y atención de las llamadas (con grabación) al que llamaremos [1], y otro exclusivamente para los cobros (sin grabación) al que llamaremos [2]. Después de que la llamada entra y el cliente ya va a comprar (todo esto se graba), la llamada se redirige al área de cobros, que recibe los datos de la tarjeta dictados por el cliente y hace el cobro (esto no se graba). De esa forma, minimizas el entorno de cumplimiento de PCI DSS solamente a [2]. Incluso, si haces que las llamadas de [2] no sean VoIP sino que sean telefonía tradicional, entonces te evitas tener la infraestructura de telecomunicaciones en el entorno.
    • Actualmente, la gran mayoría de soluciones de protección de datos para grabaciones de llamadas usan DTMF. Ese es el futuro.

    Ya me contarás qué tal te va.

  • #47785
    Avatar
    sturon
    Participante

    Buenos días,

    Pues precisamente en la compañía se estaba valorando la separación de 2 entornos, recepción (con grabación) y pago (sin grabación), e ir pasando la llamada de uno a otro. No sólo separación lógica, sino también física, valorando incluso evitar voIP en el de pago.

    Entiendo que para el traspaso de la llamada del de grabación al de pago, se admitiría la interacción del tele-operador para pulsar el botón «TRASPASAR», y ante dicho evento se dispararía el agente automáticamente que pausara/finalizara la grabación. ¿correcto?

    Gracias de nuevo!

  • #47800
    David Acosta
    David Acosta
    Participante

    Buenos días:

    En efecto. Si la llamada es transferida y esto detiene la grabación ANTES de que el cliente indique sus datos de tarjeta, con esto es suficiente. No obstante, hay que ir con mucho cuidado concienciando y formando a los terminalistas telefónicos del entorno que graba para que no cometan errores y sigan los procedimientos establecidos, evitando grabaciones no autorizadas de datos de tarjeta.

    También, si en vez de VoIP usas red telefónica conmutada te quitas un dolor de cabeza de encima y sacas del ámbito toda la infraestructura de comunicaciones telefónicas.

    Finalmente, quiero dejar claro que estas recomendaciones están basadas en el suplemento informativo de recepción de datos de tarjeta por teléfono. Puede ser que con la publicación de la nueva versión los criterios cambien y algunas cosas que te he indicado ya no apliquen, tenlo presente por favor.

    Saludos,

    David

  • #47841
    Avatar
    sturon
    Participante

    Buenos días

    Gracias por tu aporte David

    Nos surge la duda de si se puede sacar del ámbito a la infraestructura de comunicaciones telefónicas, si la llamada no grabada con la operación de tarjeta, se transfiere a un sistema de telefonía movil aislado. Creo que son comunicaciones analógicas que se de-modulan/modulan transformándose en digitales. ¿Se considerarían analógicas (y por tanto entiendo podría sacarse del ámbito), o habría que aplicar las mismas restricciones y controles que VoIP?

    Otro problema que nos ha surgido es que hay operaciones, no todas, que se hacen dando servicio a un tercero (banco), y nos exige el «SAQ-D» de PCI-DSS por considerarnos proveedor. Ello aumenta bastante el nº de controles respecto al SAQ C-VT. ¿Que opinas?

    Por supuesto considero tus respuestas como opiniones no vinculantes ;)

    Un saludo y de nuevo, gracias!

  • #47867
    David Acosta
    David Acosta
    Participante

    Buenos días:

    El tema de transferir la llamada que no se grabará (y en donde se dictarán los datos de tarjeta) a un sistema de telefonía móvil lo veo un poco extraño. No tanto por el tráfico, sino por la seguridad de la terminal móvil. Por lo menos con un teléfono fijo y con cable puedes asegurar físicamente el entorno del call center (req. 9), pero ¿con un teléfono movil, cuya característica diferencial es la movilidad? no lo veo claro. Además, estos teléfonos tienen conexión a internet, son susceptibles de malware, pueden hacer grabaciones, etc. Es casi como si me dijeras que quieres usar un ordenador (laptop) para recibir las llamadas. Mi sugerencia es no enrollarse tanto y trabajar con lo que ya se sabe que sirve, que es telefonía fija y estaciones de trabajo fijas. Como siempre he dicho, esto puede cambiar dependiendo de lo que se indique cuando se publique el Information Supplement de grabación de llamadas.

    Respecto al tema del SAQ D, los bancos te lo piden porque éste es el único SAQ que pueden presentar los proveedores de servicio (ten presente que el SAQ A, A-EP, B, B-IP, C, C-VT y D Merchant son exclusivos para comercios). Tal y como me lo has planteado, tu empresa ES un proveedor de servicios, no un comercio. Dependiendo de la cantidad de llamadas procesadas anualmente, tendrías que aplicar a un SAQ o a una auditoría (si son más de 300.000 transacciones).

    Sin embargo, lo que se puede hacer es rellenar el formulario del SAQ D pero contestando solamente los controles del SAQ C-VT y poniendo los demás a N/A. Es decir, los controles siguen siendo los mismos pero el formato del formulario cambia. Esto tendrías que consultarlo con tu banco, porque al final son ellos los que te indican el tipo de SAQ y los controles que deberías rellenar.

    Ya me dirás.

    Saludos,

    David

  • #49274
    Avatar
    Lorusso
    Participante

    Buenos días,

    He leído mucho aquí en pcihispano (por cierto gracias por la colaboración que brindan), pero aun hay algunas cosas que no logro descifrar con un caso similar al de mi amigo @sturon.
    Se contratará a un servicio externo para realizar las ventas telefónicas, que en caso de concretarse, cada uno de los datos de la tarjeta se ingresarán en una plataforma web de pago certificada PCI DSS. Al ser el contact tercerizado , obviamente contará con infraestructura propia. Mi duda es, tomando la hipótesis que el contact no es PCI, solo me debo limitar a la seguridad en los entornos fisicos , de llamada y de grabación? o debo tener en cuenta los 12 requerimientos que contemple a toda la empresa?
    Y por ultimo , en caso de que sea PCI certificado, me quedo tranquilo ?

    Espero sepan entenderme y no haber mareado a nadie , me disculpo de antemano si así fuese.
    Quedo atento a vuestros comentarios, Gracias!!

  • #49339
    David Acosta
    David Acosta
    Participante

    Buenas tardes:
    Muchas gracias a todos por vuestra participación.
    Antes que nada, me gustaría aclarar que cada empresa es diferente y cuenta con diferentes casuísticas, razón por la cual intentar englobar todos los escenarios en una única solución es imposible. Por esta razón, siempre mi consejo es contratar un asesor QSA que, con la revisión detallada del entorno de cada empresa, podrá determinar en detalle las necesidades y acciones a implementar.
    Desde mi perspectiva, al no contar con información específica de cada entorno (diagramas de red, de flujo, inventarios, etc.) intento ofrecer un consejo óptimo y generalista, con base únicamente en la descripción que otorga cada participante.
    Por otro lado, con la publicación de la versión 3.0 del suplemento informativo para la protección de datos de tarjetas en pagos por teléfono (“Information Supplement: Protecting Telephone-based Payment Card Data”) (https://www.pcihispano.com/el-pci-ssc-publica-la-nueva-version-del-suplemento-informativo-para-la-proteccion-de-datos-de-tarjetas-en-pagos-por-telefono/) muchas de las preguntas que se habían hecho en este hilo se pueden aclarar mejor, por lo que el primer paso sería revisar este documento en detalle.
    Respecto a la pregunta, asumo lo siguiente:
    – Hay dos entornos: el de la infraestructura telefónica y el del pago con un formulario web.
    – La empresa no almacenará ningún dato de tarjeta en ningún formato.
    – La recepción de la llamada y toda la infraestructura de telefonía pertenecerá al call center. La empresa no tendrá ninguna injerencia en cómo se recibe o procesa la llamada.
    – La plataforma web en donde se ingresan los datos de pago es OTRO canal que se debe analizar en detalle, dependiendo si es un formulario alojado en la página web de la empresa o es un formulario provisto directamente por un proveedor de servicios de pago al que se accede directamente.
    Limitándonos solamente a las llamadas:
    – Si el call center está certificado en PCI DSS, la empresa contratante podrá aplicar a un SAQ A (24 controles), ya que todo el canal de MOTO (Mail Order/Telephone Order) ha sido delegado en un tercero.
    – Si el call center no está certificado en PCI DSS, entonces el servicio provisto por ese call center estará dentro del alcance de la empresa y habría que entrar a analizar su infraestructura para determinar qué controles de PCI DSS le aplican (si usa VoIP, si graba la llamada, si su entorno está segmentado, etc.). Al ser un proveedor de servicios, requeriría como mínimo el SAQ D Service Provider (369 controles).
    Como se puede ver, obviamente la mejor opción es contratar un servicio que cumpla con PCI DSS y le otorgue a la empresa su documentación de cumplimiento sin mayores acciones adicionales.
    Si tienes más dudas, con mucho gusto estaré disponible.

Debes estar registrado para responder a este debate.