¿Por qué el navegador web del cliente no necesita ser compatible con PCI?

22

Una tienda en línea hipotética que acepta pagos con tarjeta de crédito tendrá que ser compatible con PCI porque recibe (transmite), procesa y posiblemente almacena números de tarjetas de crédito.

Pero el navegador web del cliente también está transmitiendo un número de tarjeta de crédito, aunque en una conexión segura, pero después de recibir en texto sin formato desde el teclado.

No podemos hacer que todos los navegadores sean compatibles con PCI, pero no puedo encontrar ninguna referencia en la especificación.

¿Dónde está escrito que el navegador web de un cliente no necesita ser compatible con PCI?

    
pregunta ixe013 06.04.2011 - 03:45
fuente

4 respuestas

20

Bueno, primero, lo que está escrito es lo siguiente: las compañías de tarjetas de pago requieren que los comerciantes cumplan con las normas PCI-DSS. PCI-DSS no se aplica a nadie que no procese transacciones con tarjeta de crédito. Los requisitos del DSS especifican control de acceso, registro, etc. Nada de esto es aplicable a un titular de tarjeta.

Los clientes no tienen los mismos contratos que los comerciantes. No hay ningún beneficio al intentar registrar la actividad en una máquina cliente. Es probable que los números de las tarjetas individuales sean robados en muchos lugares, y el costo / beneficio en el análisis forense de la computadora de una persona por su tarjeta de crédito perdida está en algún lugar por debajo de lo razonable. Finalmente, la gente simplemente no aceptará eso. Si usar una tarjeta de crédito es demasiado difícil, los emisores de tarjetas verán un volumen reducido.

    
respondido por el Jeff Ferland 06.04.2011 - 04:24
fuente
13

Este es un problema de alcance clásico con estándares de cumplimiento. Haga que el comerciante sea plenamente responsable, pero niegue completamente todos sus esfuerzos si el cliente del comerciante no protege sus navegadores.

Sin embargo, lo que sí es cuestionable para el alcance es si el comerciante tiene representantes de CSR o empleados / contratistas / consultores de cualquier tipo (back-office, a través de inteligencia de negocios, CRM, contabilidad, oficiales u otros) utilizando un navegador u otro Aplicación para acceder a los datos de la tarjeta de pago.

He escuchado que hay una exclusión para las personas elegidas por el comerciante que acceden a los datos del titular de la tarjeta de la misma manera que lo haría un cliente. Sin embargo, esto depende del QSA (el evaluador de PCI DSS) para decidir: es su responsabilidad. discreción.

Para probar que la información anterior es precisa, permítame citar el trabajo de alcance del PCI de Gene Kim , que en una serie de diapositivas, analiza el uso de GAIT-R de IIA (responsable de COSO) para la identificación de "principios" y "controles" de cumplimiento (de los cuales PCI DSS está muy cargado). Esto se describe clásicamente como "El espíritu de la ley" versus "La letra de la ley" en la justicia penal / civil y los actos de reforma legal desde la historia de la humanidad.

En las diapositivas 35 y 37 de 2010 07 BSidesLV Movilizando el PCI Resistance 1c , está claro que:

  1. Los dispositivos de Categoría 3 están fuera del alcance de PCI DSS, mientras que los dispositivos de Categoría 2 y 1 están en el alcance de PCI DSS
  2. Los dispositivos que transmiten CHD, no pueden descifrar el CHD y tampoco están conectados a través de un segmento de red virtual / física local a un dispositivo de Categoría 1 PUEDEN SER CONSIDERADOS como una Categoría 2A, 2B, 2C o incluso una Categoría 3 dispositivos
  3. De acuerdo con el alcance, el cliente (o aquellos que transmiten el CHD exactamente como un cliente) se considera un dispositivo de Categoría 3 (y, por lo tanto, fuera del alcance de las PCI DSS). El truco aquí es asegurarse de que el representante de CSR (u otro empleado / contratista / consultor comercial) no esté violando ningún otro flujo de trabajo de alcance como se indica en la diapositiva 37, como el almacenamiento en caché de CHD a través del navegador (o proxy, capa de aplicación). gateway, etc.) o guardando el CHD en la funcionalidad de autocompletado de formulario HTML del navegador
  4. Sinceramente, creo que necesitas una cerveza por responder esto
respondido por el atdre 06.04.2011 - 08:56
fuente
6

Esto ya ha sido respondido suficientemente, pero voy a reformular lo mismo:

PCI no es la ley, es un contrato entre un adquirente (compañía de tarjetas de crédito) y un comerciante. Esto significa que no puede imponer ninguna limitación al cliente, ya que no existe un contrato (vinculante) que pueda utilizarse para exigirlo. Por lo tanto, los navegadores web de los clientes obtienen un pase gratuito.

Sin embargo, esto es importante , si el comerciante que está siendo auditado posee las máquinas donde se ejecutan los navegadores web, por ejemplo, si los clientes realizan algunas operaciones usando los Las computadoras en una tienda: son una parte del alcance PCI. Obtienen cierto margen de maniobra si el riesgo que presentan es bajo, pero eso es para que el auditor decida caso por caso.

Por lo tanto, para reiterar, la única razón por la que los navegadores web de los clientes no forman parte del alcance de PCI para el comerciante es que el comerciante no puede ejercer ningún control sobre ellos. Si puede, se convierten en parte del alcance.

    
respondido por el Nakedible 01.08.2011 - 08:36
fuente
-2

Sé que esto no es una respuesta directa, pero creo que es necesario plantearlo: la idea general es que su modelo de seguridad nunca debe confiar en la seguridad del cliente, ya que el cliente puede ser malicioso, pirateado, con virus , modificado, desactualizado o mal configurado ... El servidor debe verificar que el cliente esté seguro (siguiendo los protocolos de seguridad), y si no lo está, debe negarse a servir.

    
respondido por el Marcin 01.08.2011 - 15:00
fuente

Lea otras preguntas en las etiquetas