Respuestas de foro creadas

Viendo 15 entradas - de la 241 a la 255 (de un total de 257)
  • Autor
    Entradas
  • en respuesta a: Mecanismos y Controles de Seguridad Hosting Compartido #44535
    David Acosta
    Participante

    Hola Andrés:
    Como lo comenté antes, si usas truncamiento estos datos se encontrarán fuera del alcance de cumplimiento. Pero si almacenas datos del PAN cifrado, claramente todo el escenario cambia y se deberán aplicarán todos los controles del estándar, incluyendo los requerimientos 3.5 y 3.6 asociados a las claves de cifrado. Aquí tu objetivo estará en identificar y aislar aquellos datos cifrados de los que están truncados y de acuerdo con ello establecer el entorno de cumplimiento.
    En conclusión:
    + Datos de PAN truncados: Fuera del alcance
    + Sistema que se encarga de implementar el truncado: Dentro del alcance
    + Datos de PAN cifrados: Dentro del alcance
    Saludos,
    David

    en respuesta a: Proveedor de servicios #44539
    David Acosta
    Participante

    Hola Diego:
    Trabajaré la respuesta con el ejemplo que has puesto. Llamemos a la empresa de comercio electrónico «Empresa1» y a la empresa de infraestructura «Empresa2».
    + Para la primera pregunta:
    Si Empresa1 ha implementado su propia pasarela de pagos, debe reportar de forma obligatoria su cumplimiento de PCI DSS dependiendo del nivel de transacciones anuales que procese, ya sea en una auditoría o en un SAQ.
    Respecto al cumplimiento de Empresa2, todo depende de los servicios que le ofrezca a Empresa1 y al impacto que dichos servicios tengan en la gestión de datos de tarjetas de pago. Puede ser que en sus servicios tenga acceso lógico a la red Y a los datos de tarjeta (y depende si los puede ver cifrados y si tiene o no las claves de descifrado, tokenizados, en hash, truncados o en texto claro), que tenga acceso lógico a la red pero NO a los datos de tarjeta (por ejemplo gestión de servidores, monitorización, administración de cortafuegos/IDS/IPS, soporte técnico, etc.), que tenga acceso físico al entorno de cumplimiento (proveedor de infraestructura de CPD, servicios de vigilancia privada, etc.) o que provea algún tipo de servicio asociado a desarrollo o a provisión de software. Para cada uno de estos modelos y escenarios Empresa1 debe definir un proceso de gestión de proveedores y clausulado conforme con el requerimiento 12.8 de PCI DSS. Parte del principio que cuando se trabaja con terceros el riesgo se está delegando y la única forma de gestionarlo es mediante acuerdos contractuales.
    Es importante tener presentes las opciones que PCI DSS v3.0 describe en el apartado «Uso de proveedores de servicios externos/tercerización»:
    «…
    Los terceros proveedores de servicios tienen dos formas de validar el cumplimiento:
    1) Pueden realizar una evaluación de las PCI DSS por cuenta propia y proporcionar evidencia a sus clientes a fin de demostrar el cumplimiento; o
    2) Si no realizan la evaluación de las PCI DSS por cuenta propia, deberán solicitar la revisión de sus servicios durante el curso de cada una de las evaluaciones de las PCI DSS de sus clientes.
    …»
    Siendo así, es MUY IMPORTANTE que en el proceso de gestión de proveedores se IDENTIFIQUEN los controles y responsabilidades que serán cubiertos por parte y parte y la forma como se evaluarán.
    + Para la segunda pregunta:
    Se debe revisar de forma detallada el flujo de transmisión de datos hacia el centro autorizador por parte de Empresa1. Como sabes, en la versión 3.0 de PCI DSS se definieron modelos nuevos de SAQ entre los que se encuentran el SAQ A y el SAQ A-EP que cubren dos escenarios similares con la diferencia de la forma como se envían los datos al centro autorizador y ambos incluyen el requerimiento 12.8 de gestión de proveedores. En este caso, volvemos al mismo punto de arriba en el que habría que validar los servicios prestados por Empresa2 y el nivel de acceso y riesgo al entorno de cumplimiento.
    Lamentablemente con la información proporcionada es muy difícil poder darte una respuesta puntual y ajustada al entorno de las empresas que describes, por lo que he intentado ser lo más generalista posible.
    Finalmente, en el «Appendix B: Merchant and Third-Party PCI DSS Responsibilities» del documento «Information Supplement: PCI DSS E-commerce Guidelines» puedes encontrar respuesta a las preguntas adicionales que puedas tener: https://www.pcisecuritystandards.org/pdfs/PCI_DSS_v2_eCommerce_Guidelines.pdf
    Espero que esta información te sea de utilidad.
    Saludos,
    David

    en respuesta a: QSA #44538
    David Acosta
    Participante

    Comentar adicionalmente que los costes (fees) que deben ser pagados al principio o en la recertificación anual de cada uno de los programas del PCI SSC se puede encontrar en esta ubicación: https://www.pcisecuritystandards.org/security_standards/fees.php

    en respuesta a: Hardening a Unidades de Almacenamiento SAN #44536
    David Acosta
    Participante

    Hola Andrés:
    En este caso – y para contestarte de forma específica – tendría que conocer el fabricante de la solución y el modelo.
    De forma general, en la página web del SANS Institute puedes encontrar varios documentos que te pueden servir:
    https://www.sans.org/reading-room/whitepapers/storage/securing-networked-storage-defense-in-depth-1132
    http://it-audit.sans.org/community/papers/security-risk-assessment-audit-emc-san_48
    Por otro lado, muchas veces en las guías de administración o de operación de dichas plataformas se incluyen una serie de acciones técnicas orientadas a la parte de seguridad que te pueden ser útiles para desarrollar tu propia guía de configuración segura.

    en respuesta a: Mecanismos y Controles de Seguridad Hosting Compartido #44533
    David Acosta
    Participante

    Buenas tardes:

    Para contestarte, me remitiré a la FAQ «Are truncated Primary Account Numbers (PAN) required to be protected in accordance with PCI DSS?»:
    «…Systems that store only truncated PANs (where a segment of PAN data has been permanently removed) may be considered out of scope for PCI DSS if that system is adequately segmented from the cardholder data environment, and does not otherwise store, process or transmit cardholder data or sensitive authentication data. However, the system performing the truncation of the PANs, as well as any connected systems and networks, would be in scope for PCI DSS…»
    https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Are-truncated-Primary-Account-Numbers-PAN-required-to-be-protected-in-accordance-with-PCI-DSS

    De acuerdo con ello, si dentro de tu entorno almacenas el PAN truncado tal como se estipula en la FAQ «What are acceptable formats for truncation of primary account numbers» https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/What-are-acceptable-formats-for-truncation-of-primary-account-numbers, estos datos se encontrarían fuera del alcance de cumplimiento de PCI DSS y los controles de seguridad que tendrías que aplicar serían los de tu propia Política de Seguridad Corporativa. Dentro del entorno de PCI DSS se encontraría el sistema que se encarga de implementar el truncado como tal, ya que dentro de su lógica se encuentra la obtención del PAN completo para truncarlo.

    Si por el contrario se está almacenando el PAN bajo cualquier otro formato (cifrado o en hash, por ejemplo), los controles que aplicarían serían diferentes. Igualmente, si el truncado no se realiza como lo estipula el PCI SSC es necesario implementar controles adicionales.

    Más información en:
    https://usa.visa.com/download/merchants/pan_truncation_cardholder.pdf

    Haz clic para acceder a PAN_truncation_best_practices.pdf

    en respuesta a: QSA #44537
    David Acosta
    Participante

    Buenas tardes:

    Respecto al proceso de formación de QSA es importante tener presente que el QSA debe trabajar a tiempo completo (full time) a una empresa listada en el sitio web del PCI SSC como «Qualified Security Assessor Companies»: https://www.pcisecuritystandards.org/approved_companies_providers/qualified_security_assessors.php
    Dichas empresas deben demostrar que cuentan con personal especializado y certificado, con amplia experiencia en el campo de la seguridad de la información y con criterios objetivos para realizar una auditoría que cumpla con los requerimientos de las normativas. Así mismo, deben aprobar una auditoría exhaustiva, pagar unos costes de mantenimiento anuales y en función de los resultados, calidad de sus auditorías y feedback de sus clientes pueden ser auditadas nuevamente por el SSC.

    Respecto al QSA, un profesional certificado PCI DSS QSA (Qualified Security Assessor) se encuentra capacitado para ofrecer consultoría objetiva y realizar auditorías de cumplimiento de PCI DSS (sólo una auditoría realizada y validada por un QSA es válida ante el PCI SSC). Dichos profesionales deben pertenecer a una empresa homologada. Esto es: No se pueden hacer auditorías a título personal o sin pertenecer a una empresa homologada.

    El proceso de certificación (a grandes rasgos) es el siguiente:
    – Pertenecer a una empresa homologada, trabajar en dicha empresa a tiempo completo (full time) y pagar una membresía anual.
    – Rellenar el formulario de aplicación demostrando experiencia (mínimo 5 años) y certificaciones relacionadas (CISSP, CISA o CISM).
    – Asistir a una formación presencial específica de QSA ofrecida por el PCI SSC (primera vez) u online (recertificación) anual que incluye un examen.
    – Para recertificación: demostrar un cumplimiento de 120 CPE (Continuing Education Credits) anuales
    – Aceptar las políticas de gestión del PCI SSC.
    – Aparecer publicado en las listas de QSA.
    – Puede certificar entornos P2PE con una formación adicional.

    Más información en https://www.pcisecuritystandards.org/documents/qsa_validation_requirements.pdf

    Así mismo, el PCI SSC puede revocar la certificación a un profesional con base en una serie de criterios específicos. Más información en https://www.pcisecuritystandards.org/documents/QSA_and_PA-QSA_Revocation_FAQ.pdf

    en respuesta a: Como revisar los controles «grises» #44527
    David Acosta
    Participante

    Hola:
    En este caso la respuesta es una sola palabra: segmentación.
    Tanto los escaneos internos y externos de vulnerabilidades (req. 11.2) y las pruebas de penetración internas y externas (req. 11.3) deben cubrir todos los elementos que se encuentren en el entorno de cumplimiento. Si los equipos que procesan, almacenan o transmiten datos de tarjetas de pago se encuentran en el mismo segmento que otros equipos que no interactúan con tarjetas, directamente dichos equipos entran en el entorno. Por eso, una forma de minimizar el alcance es empleando segmentación. En el estándar PCI DSS v3.0 (que puedes descargar aquí: http://www.pcihispano.com/pci-dss-y-pa-dss-v3-0-disponibles-en-espanol/) encontrarás los apartados «Alcance de los requisitos de las PCI DSS» y «Segmentación de red» y el Anexo D: «Segmentación y muestreo de instalaciones de negocios/Componentes de sistemas» que definen cómo se debe segmentar y evaluar la validez de dicha segmentación para definir qué equipos entran o no en el alcance.
    Así mismo, en la versión 3.0 de PCI DSS viene un nuevo requerimiento (req. 11.3.4) que establece la necesidad de ejecutar pruebas de penetración para validar la segmentación si ha sido implementada en el entorno.
    En conclusión: Las pruebas de penetración tienen que cubrir TODOS los elementos del CDE. Si no existe segmentación, todos los elementos que convivan dentro del mismo segmento de red en donde se encuentran equipos cubiertos por PCI DSS deberán ser analizados también. Si existe segmentación, la prueba deberá validar que la segmentación está correctamente implementada.
    Espero que esta respuesta te sea de utilidad.
    Saludos,
    David

    en respuesta a: Cumplimiento de PCI DSS #44512
    David Acosta
    Participante

    Comentar que gracias a este hilo de discusión he redactado el artículo «Todo lo que siempre ha querido saber acerca de los SAQ (Cuestionarios de Auto-evaluación)» http://www.pcihispano.com/todo-lo-que-siempre-ha-querido-saber-acerca-de-los-saq-cuestionarios-de-auto-evaluacion/. Gracias a todos por las ideas.

    en respuesta a: Equipo de Respuestas a Incidentes #44529
    David Acosta
    Participante

    Hola Andrés:
    Supongo que el equipo de Respuesta a Incidentes que quieres implementar en tu empresa será para atender incidentes relacionados con tarjetas de pago propias de transacciones comerciales asociadas a tu negocio. En este caso, el estándar PCI DSS v3.0 (que puedes encontrar aquí: http://www.pcihispano.com/pci-dss-y-pa-dss-v3-0-disponibles-en-espanol/) en su requerimiento 12.10 define una serie de criterios a tener en cuenta para la definición de dicho plan:
    – Roles, responsabilidades y estrategias de comunicación y contacto en caso de un riesgo que incluya, como mínimo, la notificación de las marcas de pago.
    – Procedimientos específicos de respuesta a incidentes.
    – Procedimientos de recuperación y continuidad comercial.
    – Procesos de copia de seguridad de datos.
    – Análisis de los requisitos legales para el informe de riesgos.
    – Cobertura y respuestas de todos los componentes críticos del sistema.
    – Referencia o inclusión de procedimientos de respuesta ante incidentes de las marcas de pago.
    Igualmente, requiere que se haga de una prueba de dicho plan por lo menos anualmente (req. 12.10.2), que exista personal disponible 7×24 para atender alertas (req. 12.10.3), que el personal tenga formación en gestión de incidentes (req. 12.10.4), que se incluyan las alertas de sistemas de monitorización de seguridad (req. 12.10.5) y un proceso de mejora continua con base en las lecciones aprendidas (req. 12.10.6).
    Como ves, son indicaciones generales que debes desarrollar adaptadas a tu negocio y al potencial riesgo que tengas. Cada incidente es interpretado de diferente forma por cada entidad, por lo que el primer paso es definir precisamente «qué es un incidente» dentro de tu entorno.
    En cuanto a un CSIRT, considero que es si estás en una empresa pequeña la figura de un CSIRT es muy compleja. Sin embargo, en el web site de ENISA puedes encontrar una guía muy completa y en español que te puede dar una idea del concepto, servicios y pasos para crear un centro como estos: https://www.enisa.europa.eu/activities/cert/support/guide/files/csirt-setting-up-guide-in-spanish
    Saludos,
    David

    en respuesta a: Lista negra de tarjetas y PCI DSS #44522
    David Acosta
    Participante

    Hola:
    Si entiendo el escenario que planteas sería así:
    APLICA PCI DSS: PAN no está en lista negra
    NO APLICA PCI DSS: PAN esta en lista negra
    Ahora, el PAN se vuelve a activar (ha salido de la lista negra). En el momento en el que recibes la notificación ya sea del centro autorizador o del proveedor de los listados de tarjetas fraudulentas, se deben re-activar los controles para ese PAN (req. 3.4).
    Tengamos en cuenta que el estándar PCI DSS está orientado a la protección del PAN, por lo que los movimientos realizados con esa tarjeta (supongo que te refieres a los registros de las transacciones) no tienen nada que ver con este estándar y serían cubiertos por la Política propia de la organización, obviamente siempre y cuando no tengan referencia al PAN.
    ¿Te he entendido bien? Si no, estaré pendiente a tu respuesta.

    en respuesta a: Grupos de empresas #44528
    David Acosta
    Participante

    Hola Diego:
    Para los temas de certificación en PCI DSS, el reporte de cumplimiento se tiene que enviar a cada marca y ya son ellos directamente los que procesan cada caso. Por darte un ejemplo: Si eres un Service Provider en Europa y quieres reportar a Visa, es necesario que te registres como Visa Merchant Agent https://www.visamerchantagents.com/. Allí, uno de los requisitos principales es que notifiques el registro mercantil y los datos de impuestos de la empresa que vas a dar de alta. Al ser estos datos asociados a una única entidad, se puede dar por entendido que si cada empresa del grupo tiene datos diferentes pues es necesario inscribirlas de forma independiente.
    Sin embargo, en la FAQ de dicha página https://www.visamerchantagents.com/faq hay información que te puede ser de utilidad:
    =====================
    Pregunta: My organisation has multiple brand names or products but share one PCI DSS assessed card data infrastructure. Do I need to register multiple times for each product or trading name?
    Respuesta: During the registration process you have the ability to indicate several TRADING AS names, which will appear as such on http://www.visamerchantagentslist.com under the category «Agent Website.»
    Pregunta: My organisation has multiple PCI DSS assessed card data infrastructures. Do I need to register multiple times for each PCI DSS assessed infrastructure?
    Respuesta: Unfortunately, the current registration process does not allow one merchant agent to register multiple PCI DSS assessments for different card data environments as one merchant agent listing. You have to create a new merchant agent entry for each assessment separately.
    ======================
    Mi recomendación es que consultes directamente a las marcas con las que estás trabajando y les hagas esta pregunta. En función de sus propias políticas lo pueden analizar y darte opciones, mira esta respuesta:

    If you have multiple card data environments, please contact [email protected] on how to proceed to aggregate the multiple registrations under one fee calculation for the final listing on http://www.visamerchantagentslist.com. If you advise us after you have paid your merchant agent registration fees that your business has been registered multiple times, we will be unable to provide you with a refund.

    En el caso de comercios que reportan cumplimiento a través de un SAQ, puedes comunicarte con el centro autorizador que les ha hecho el requerimiento. Ya son ellos a su discreción los que pueden definir cómo proceder.

    Finalmente, esta información no está especificada en ningún lugar y son temas al margen de los propios estándares (que son gestionados por el PCI SSC). Son políticas de los propios adquirientes, de las marcas o de los proveedores de servicio e inclusive puede variar de país a país…

    Espero que esta información te sea de utilidad.
    Saludos,
    David

    en respuesta a: Cumplimiento de PCI DSS #44510
    David Acosta
    Participante

    Hola Ekn:
    Por lo general el SAQ (Cuestionario de Auto-Evaluación) es requerido por la entidad que te ofrece el servicio de autorización, ya que son ellos quienes pueden determinar tu nivel de comercio o de proveedor de servicios dependiendo de la cantidad de transacciones anuales que proceses y/o de los canales de pago que tengas asociados. Siendo así, consulta con tu banco o caja y ellos sabrán darte una respuesta apropiada con base en sus políticas internas.
    El PCI SSC simplemente se encarga de la gestión de los estándares, pero la administración de niveles de cumplimiento, reportes y penalizaciones (entre otros) lo llevan las propias marcas o las empresas que ellos designen.
    Saludos,
    David

    en respuesta a: Como revisar los controles «grises» #44525
    David Acosta
    Participante

    Buenos días:
    Antes que nada, gracias por participar.
    + Respecto a la primera pregunta relacionada con el requisito 10.4.2: Son dos partes. 1) Cuando se habla acerca de control de acceso a las configuraciones del sistema y valores de configuración se refiere a permisos en los ficheros de configuración, ya sean DAC (Control de Acceso Discrecional), MAC (Control de Acceso Mandatorio) o RBAC (Control de Acceso basado en Roles). Es decir: revisión de permisos. La idea detrás de este requerimiento es garantizar que nadie más salvo el personal autorizado pueda cambiar las configuraciones del sistema de tiempo de la organización. Por ejemplo: En el caso de NTP, validar los permisos del fichero de configuración ntp.conf. 2) Se habla también de «acceso a los datos de tiempo», es decir al servicio como tal. Para ello, la idea es validar que existan una serie de restricciones (ACL, por ejemplo) que limiten el acceso al servidor. Por ejemplo: En ntp.conf esto se puede implementar con la directiva «restrict».
    Muchos de estos parámetros deberían estar descritos en la guía de configuración segura del servicio de NTP que debería hacer parte del control 2.2 y en este requisito simplemente se validan que estén configurados de forma correcta para gestionar el riesgo de manipulación no autorizada del servicio.
    + Respecto a la pregunta del requisito 10.4.3, se habla de «fuentes aceptadas por la industria». El Navigating de PCI DSS v2.0 dice «…More information on NTP can be found at http://www.ntp.org, including information about time, time standards, and servers…». Es decir: en función de tu ubicación geográfica puedes usar un servidor de los descritos en http://www.ntp.org. Por otro lado, en cada país siempre se tiene un servidor de tiempo oficial. Para el caso de España el servidor de tiempo es el servidor del Real Instituto y Observatorio de la Armada (http://www.armada.mde.es/ArmadaPortal/page/Portal/ArmadaEspannola/ciencia_observatorio/prefLang_es/), en México el Centro Nacional de Metrología (CENAM), en Colombia el Instituto Nacional de Metrología y en Chile el Servicio Hidrográfico y Oceanográfico de la Armada de Chile (SHOA), por solo nombrar algunos.
    + Respecto al control 8.4: La descripción de criptografía sólida (Strong Cryptography) la puedes encontrar en el glosario de PCI DSS:
    «… Strong Cryptography:
    Cryptography based on industry-tested and accepted algorithms, along with strong key lengths and proper key-management practices. Cryptography is a method to protect data and includes both encryption (which is reversible) and hashing (which is not reversible, or “one way”). Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (1024 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher). See NIST Special Publication 800-57 (www.csrc.nist.gov/publications/) for more information…» https://www.pcisecuritystandards.org/security_standards/glossary.php#S
    En Windows, las contraseñas son generadas y almacenadas empleando un algoritmo de hash. Dependiendo de la versión del sistema operativo y de su configuración, se generan dos tipos de claves: LAN Manager hash (LM Hash) y Windows NT hash (NT hash – basado en MD4) que se almacenan en el fichero Security Accounts Manager (SAM) ubicado en C:WindowsSystem32configSAM y en Active Directory en C:WindowsNTDSntds.dit. Adicionalmente, para prevenir volcados de estos ficheros de hash se emplea un cifrado empleando una clave denominada SYSKEY. Más información en http://support.microsoft.com/kb/102716
    El uso de un algoritmo o de otro en Windows depende de la configuración de tu servidor y para ello, dicha configuración debe ser establecida en la guía de configuración segura de esta plataforma.
    Espero que esta información te sea de utilidad.
    Saludos,
    David

    David Acosta
    Participante

    Hola Carlos:

    Entiendo tus comentarios. El estándar PCI DSS (al igual que otros estándares y normativas) trata de ser lo suficientemente genérico para aplicar tanto a un comercio pequeño como a un proveedor de servicios internacional, pero a la vez trata de cubrir al máximo los detalles lógicos, físicos y administrativos delegados en estas tareas. Siendo así – y lo digo por experiencia en implementación y auditoría – siempre se encuentran escenarios atípicos. Y es aquí en donde vienen las ambigüedades y las diferentes interpretaciones entre los QSA o ISA encargados de los proyectos. Lo que debe primar en este tipo de casos es la gestión óptima del potencial riesgo identificado, en donde pesa bastante el criterio y la experiencia de la persona que te esté asesorando en el proceso.

    Ahora bien, respecto al cumplimiento. La recomendación del PCI SSC es que si no se requieren almacenar, procesar o transmitir datos de tarjeta, no se haga (ver http://www.pcihispano.com/una-revision-a-los-10-mitos-comunes-de-pci-dss/ MITO 9: PCI DSS obliga a almacenar datos de tarjetas). Si definitivamente por una justificación técnica o administrativa requieres acceder a datos de tarjetas de pago, los controles que te aplicarán dependerán de tu tipo de servicio (comercio o proveedor de servicios), los canales de pago presentes y la cantidad de transacciones anuales que proceses. Con estas variables, sabrás si tienes que asumir una auditoría o un Cuestionario de Evaluación, que puede ser del tipo A (13 preguntas), B (29 preguntas), C (40 preguntas), C VT (51 preguntas) o D (288 preguntas) y si te aplican o no escaneos ASV.

    Por poner un ejemplo sencillo alineado a tu pregunta: Un comercio que almacena datos de tarjetas de pago (PAN) para transacciones recurrentes (un cobro periódico o un cliente que no quiere digitar los datos de su tarjeta cada vez que hace una compra). Digamos que es un comercio electrónico y tiene un servidor web, un servidor de aplicaciones y una base de datos (3 equipos independientes). Tiene varias opciones para trabajar con base en una gestión del riesgo:
    + Minimizarlo: Puede optar por hacerlo él mismo (es decir: implementar todos los servicios con su propia infraestructura). Dependiendo de la cantidad de transacciones anuales, debe cumplir con un SAQ D o con una auditoría, con lo cual le aplican todos (o la gran mayoría) de controles del estándar. Para minimizar el potencial riesgo de tener todo este proceso in-house, debe aplicar los controles de PCI DSS, lo cual le implicaría implementar firewalls, antivirus, FIM (File Integrity Monitoring), servidor de log centralizado, servidor de NTP, WAF (Web Application Firewall), IDS/IPS, por solo nombrar algunos y obviamente todo el marco normativo y procedimental asociado.
    + Transferirlo: Así mismo, puede optar por delegar en un tercero ciertos controles de PCI DSS, por ejemplo en un proveedor de hosting seguro que cumpla con PCI DSS. Obviamente, los costes no serán los mismos que un hosting normal, pero de esa forma delega el cumplimiento de determinados controles a un tercero y los refuerza con el control 12.8 (gestión de proveedores). O puede contratar una empresa certificada en PCI DSS que capture, almacene, procese y transmita los datos de tarjeta a su nombre y aplicar a un SAQ A (13 preguntas).
    + Eliminarlo: Hacer un análisis coste/beneficio de darle este servicio al cliente (que implicaría cumplir todos los controles de la normativa) o retirar este servicio y de esta forma minimizar el cumplimiento al mínimo.
    Obviamente, asumir el riesgo no es una opción válida.

    Como ves, todo es cuestión de coste/beneficio.

    Respecto al apartado de ingreso manual de datos a través de un TPV. Aquí hay que hacer varias aclaraciones:
    + Si eres tu el que ofrece ese servicio (por ejemplo: personal de tu empresa en un call center que capturan los datos de la tarjeta y los digitan en un TPV Virtual) debes aislar los equipos que efectúan esta tarea. Aquí aplicarían los controles del SAQ C y SAQ C VT.
    + Si es tu cliente quien los digita (por ejemplo: yo como comprador en tu tienda virtual) pues tu no puedes aplicar controles sobre un equipo que no puedes gestionar (mi ordenador, en este caso), por lo cual esos equipos están fuera del alcance.

    Siento si se ha quedado algo por fuera pero tampoco quiero hacer la respuesta más larga. Espero que te sea de utilidad. O si prefieres, abre diferentes discusiones con temas puntuales, para que las respuestas sean más específicas.

    Saludos,

    David

    en respuesta a: Cumplimiento de PCI DSS #44508
    David Acosta
    Participante

    Hola Diego:
    El PCI SSC como tal es el responsable de la publicación de los estándares y actividades de promoción relacionadas, entre otras funciones. Las políticas de cumplimiento y penalizaciones las define cada marca:
    «…Note that enforcement of compliance with the PCI DSS and determination of any non-compliance penalties are carried out by the individual payment brands and not by the Council. Any questions in those areas should be directed to the payment brands…» (https://www.pcisecuritystandards.org/organization_info/index.php)
    En este caso, lo que tu estás buscando no lo encontrarás en los documentos del Council sino directamente con la marca. Para ello, puedes contactarlos en [email protected] o directamente a Diners Club España en [email protected] y http://www.dinersclub.es/diners-club/localizacion.
    Saludos,
    David

Viendo 15 entradas - de la 241 a la 255 (de un total de 257)