Respuestas de foro creadas

Viendo 15 entradas - de la 1 a la 15 (de un total de 257)
  • Autor
    Entradas
  • en respuesta a: pagos con QR #56660
    David Acosta
    Participante

    Hola Jordi:
    En términos generales, la tecnología QR se emplea como elemento de interacción entre el comercio y el comprador para permitir inicializar una transacción. En los pagos presenciales con tarjetas, tradicionalmente el comercio digita el coste del producto y presenta un dispositivo especial (datáfono) para capturar los datos de la tarjeta del cliente ya sea por lectura de banda, chip EMV o contactless. En pagos con QR ocurre algo similar, solo que el comercio presenta un codigo QR al cliente para que lo lea en su dispositivo móvil o tablet y desde ahí ejecute el pago, ya sea activando una aplicación o rellenando un formulario.
    En estos casos, más que hablar de «pagos por QR» se debería hablar de «transacciones empleando QR», ya que el código QR no implica el pago como tal ni remplaza un método de pago, solamente permite establecer un enlace entre el comercio y el cliente y luego se realiza el pago empleando otros métodos (app en el móvil, digital wallet, PayPal, etc.). En esta URL puedes encontrar más detalles: https://www.mobiletransaction.org/qr-code-payment-works/ y aquí puedes encontrar ejemplos para generar códigos QR para emplearlos en transacciones de pago: https://www.qrcodechimp.com/qr-code-generator-for-payments

    en respuesta a: Permisos admin staff tecnico #56659
    David Acosta
    Participante

    Buenas tardes:
    El estándar PCI DSS requiere que exista una separación de responsabilidades entre los entornos de desarrollo/pruebas y el entorno de Producción (req. 6.4.2). Textualmente, la guía de este requisito indica que:
    «The intent of this requirement is to separate development and test functions from production functions. For example, a developer may use an administrator-level account with elevated privileges in the development environment, and have a separate account with user-level access to the production environment».
    Esto quiere decir que no hay problema en que los desarrolladores tengan permisos administrativos en su entorno de desarrollo/test. No obstante, su acceso al entorno de Producción debe estar limitado.

    en respuesta a: Sanciones en caso de incumplir PCI DSS #56658
    David Acosta
    Participante

    Hola David:
    Hay varias formas de gestionar este tema:
    – La gestión de reclamaciones vinculadas con pagos por lo general la debe hacer el cliente en su banco. En ese punto, es el banco el que se encarga de realizar las verificaciones correspondientes con las entidades relacionadas con ese pago (desde el comercio hasta cualquier pasarela de pago intermedia).
    – Si tu empresa es un comercio, puedes hacer revisiones internas proactivas para comprobar que todo está correcto en lo que corresponde a tu responsabilidad, dependiendo si el pago se ha tramitado por comercio electrónico o por canales presenciales (datáfonos) y correlacionar la información que os provee el usuario respecto al problema (que su tarjeta se usó de forma fraudulenta en otro comercio, que se hicieron otras compras con la misma tarjeta, etc.).
    Como sabes, cualquier empresa que almacene, procese y/o trasmita datos de tarjetas de pago debe cumplir con PCI DSS. Esto implica que estas acciones deberían estar recogidas en un documento de respuesta a incidentes de tu empresa, al margen de que uses un cuestionario de autoevaluación (SAQ) o una evaluación formal para comprobar el cumplimiento. Aquí tienes mayor información: https://www.pcihispano.com/como-proceder-ante-un-compromiso-de-datos-de-tarjetas-de-pago/
    En el peor de los casos, si se detecta un fraude masivo o un compromiso de datos, la entidad adquiriente (banco o pasarela de pagos) o las propias marcas de pago pueden proceder con acciones correctivas dependiendo de la cantidad de datos afectados. Puedes encontrar más información en el apartado «¿Qué ocurre si no se cumple con PCI DSS?» del artículo «Qué es PCI DSS?» https://www.pcihispano.com/que-es-pci-dss/».
    No obstante, si el incidente está vinculado con una única tarjeta de forma aislada, lo mejor es que el cliente ponga la reclamación en su banco y que la revisión siga su curso normal. De todas formas, revisa con calma internamente para comprobar que la responsabilidad no es tuya.
    Saludos,
    David

    en respuesta a: Pentest en la nube #55528
    David Acosta
    Participante

    Hola Paco:
    Antes que nada, es importante diferenciar entre una cuenta de MS Azure, una suscripción y una cuenta de directorio (Azure Account, Subscription and Directory):
    «The Azure account is a global unique entity that gets you access to Azure services and your Azure subscriptions. You can create multiple subscriptions in your Azure account to create separation e.g. for billing or management purposes. In your subscription(s) you can manage resources in resources groups. Azure subscription can have a trust relationship with an Azure Active Directory (Azure AD) instance«.
    En este caso, el alcance del pentest interno está descrito en el Information Supplement: Penetration Testing Guidance (https://www.pcisecuritystandards.org/documents/Penetration-Testing-Guidance-v1_1.pdf):
    «The scope of the internal penetration test is the internal perimeter of the CDE and critical systems from the perspective of the internal network. Testing must include both application-layer and network-layer assessments.»
    Esto quiere decir que se deberían analizar las redes colindantes con el CDE a nivel interno.
    Si las redes no están conectadas con el CDE (como sería el caso de las suscripciones, siempre y cuando se hayan implementado de forma correcta los elementos de segmentación y aislamiento), entonces la prueba asociada no es el pentest interno, sino el pentest de segmentación:
    «The intent of segmentation is to prevent out-of-scope systems from being able to communicate with systems in the CDE or impact the security of the CDE. When properly implemented, a segmented (out-of-scope) system component could not impact the security of the CDE, even if an attacker obtained control of the out-of-scope system. If segmentation controls are implemented, testing of the controls is required to confirm that the segmentation methods are working as intended and that all out-of-scope systems and networks are isolated from systems in the CDE. The scope of segmentation testing should consider any networks and systems considered as being out of scope for PCI DSS to verify they do not have connectivity to the CDE and cannot be used to impact the security of the CDE
    Espero que esta información sea útil.
    Saludos,
    David

    en respuesta a: Medídas de control físico en PCI PIN 3.x #55527
    David Acosta
    Participante

    Hola Rubén:
    De acuerdo con PCI PIN, cuando se generan claves criptográficas y se imprimen sus componentes (req. 6-3) y cuando se cargan componentes en claro sin el uso de SCDs (req. 13-2) se requiere el uso de una sala segura. Esta es una de las principales razones por las cuales los servicios de HSM en la nube (cloud) de los principales proveedores (AWS, Azure, GCP) no pueden ser empleados en entornos PCI PIN.
    No obstante, si en tu entorno criptográfico solamente se usan de forma exclusiva tarjetas inteligentes (smart cards) en donde los componentes almacenados se encuentran encriptados, es posible que estos dos requerimientos (y por tanto, el uso de salas seguras) no sea requerido.
    El gran problema viene cuando tienes que conectarte con terceros (adquirientes, centros autorizadores e incluso las redes de las propias marcas de pago) y requieres realizar intercambio de claves mediante componentes y ese tercero no cuenta con una infraestructura de smart cards compatible con la tuya. En esos casos, la única salida válida es el uso de componentes impresos, lo cual nos lleva inevitablemente al uso de salas seguras.
    Espero que esta información te sirva.

    en respuesta a: Nivel de proveedor y número de transacciones #54788
    David Acosta
    Participante

    Buenas tardes:
    Esta es una pregunta muy interesante, ya que no hay una respuesta única.
    El concepto de qué es una «transacción» depende de cada marca de pago. Recordemos que el estándar PCI DSS es gestionado por el PCI Security Standards Council (PCI SSC) pero la definición de quién tiene que cumplir con este estándar es responsabilidad de las marcas de pago, quienes gestionan los niveles de cumplimiento tanto para comercios como de proveedores de servicio de forma unilateral. Aquí puedes encontrar un artículo que habla de ello (https://www.pcihispano.com/niveles-de-cumplimiento-y-requerimientos-de-las-marcas-para-comercios-y-proveedores-de-servicio-en-pci-dss/).
    En términos generales, se usa el criterio de «transacción» (entendiéndose como una autorización o no de un pago realizado con una tarjeta perteneciente a una marca específica) para identificar los niveles de cumplimiento. No obstante, este concepto no siempre aplica.
    En casos en los que una entidad solamente almacena datos de tarjetas pero no hay ninguna acción de envío para autorización ni conexión con adquirientes o con las marcas (por ejemplo: una empresa que ofrece servicios de tokenización), en ese caso el concepto de «transacción» no se aplica, sino que se cuentan cuantas tarjetas se almacenan anualmente. Como ves, el criterio varía dependiendo del tipo de servicio ofrecido.
    Otras veces, hay entidades que debido a su riesgo o si han tenido incidentes con tarjetas anteriormente, su nivel no se define en términos de transacciones, sino en términos de riesgo (a mayor riesgo, mayor nivel de cumplimiento).
    En este caso, lo más aconsejable es contactar con la entidad adquiriente (bancos) o con las marcas para que sean ellos, de acuerdo con sus criterios, quienes definan los requisitos y los niveles en los que recae una empresa dependiendo de los canales de pago disponibles, de sus servicios y del riesgo a fraudes que tenga.
    Finalmente, comentar que los asesores QSA no definen el nivel de cumplimiento de una empresa ni tienen ninguna injerencia en este proceso.
    Saludos,
    David

    en respuesta a: Requisito 8.7 #54756
    David Acosta
    Participante

    Buenos días:
    El objetivo del control 8.7 es garantizar que solamente los DBA tengan acceso directo a las bases de datos. En ese sentido, todas las demás cuentas que hacen uso de la base de datos (incluyendo usuarios interactivos y aplicaciones) deben emplear métodos programáticos (https://es.wikipedia.org/wiki/Procedimiento_almacenado) precisamente para restringir los datos a los que se tiene acceso en función de los privilegios asignados a cada cuenta y controlar la entrada y salida de datos.
    Si se requiere acceso a las bases de datos por parte de otro rol diferente al de DBA, hay diferentes opciones que hay que analizar dependiendo del escenario y del potencial riesgo:
    – Que sea un DBA el encargado de la extracción de los datos/archivos que se necesiten para efectos de soporte técnico.
    – Que el personal de soporte técnico pueda visualizar lo que necesite mediante el acompañamiento de un DBA (empleando pantallas compartidas, por ejemplo)
    En el caso que que esto no sea suficiente (y dependiendo del tipo de soporte técnico requerido), se puede crear una cuenta temporal con las restricciones necesarias (usando vistas, por ejemplo) para evitar que esa persona pueda visualizar/acceder a datos de tarjetas. Para este caso en particular tienes el control 8.1.5 que permite que el personal técnico (generalmente de empresas externas de soporte) puedan acceder al entorno de forma segura (limitado en el tiempo y monitorizado).
    Igualmente, si el personal de soporte técnico requiere la extracción de logs, archivos de depuración, volcados de memoria, etc. se debe cumplir con lo descrito en el requerimiento 12.3.10, protegiendo siempre la información de tarjetas.
    De acuerdo con lo descrito anteriormente, no se requiere de un control compensatorio, ya que el propio estándar incluye controles especiales para la gestión de estos casos en los cuales se necesita acceso remoto y soporte técnico por parte de terceros.
    Saludos,
    David

    en respuesta a: Pan En Claro #54391
    David Acosta
    Participante

    Buenas tardes:
    En el caso que exista una justificación técnica o administrativa que impida la implementación del requerimiento de PCI DSS conforme lo indica el estándar, se puede emplear un control compensatorio (https://www.pcihispano.com/controles-compensatorios-que-son-y-cuando-se-utilizan/). Es importante tener en cuenta que para la elección y validación de dichos controles es altamente recomendable emplear el soporte de un asesor QSA para evitar problemas futuros.
    Respecto al almacenamiento, el requerimiento 3.4 ofrece diferentes alternativas para proteger los datos del PAN de forma segura:
    – Usando criptografía fuerte (https://www.pcihispano.com/que-algoritmos-criptograficos-se-deben-emplear-para-cumplir-con-pci-dss/)
    – Usando funciones criptográficas de ua sola vía (one-way) o hash
    – Usando tokenización (https://www.pcihispano.com/el-concepto-de-tokenizacion-y-su-aplicabilidad-en-pci-dss/)
    – Usando truncamiento (https://www.pcihispano.com/diferencias-entre-enmascaramiento-y-truncamiento-en-pci-dss/)
    Adicionalmente, si los datos son almacenados en un medio de almacenamiento removible, se puede emplear la encriptación a nivel de disco (https://www.pcihispano.com/consideraciones-para-el-cifrado-de-disco-y-cumplir-con-el-requisito-3-4-1-de-pci-dss/).
    La alternativa que comentas (usar encriptación PGP) es un formato correcto de almacenamiento que cumple con el requerimiento 3.4 (criptografía fuerte). No obstante, si se usa criptografía, los requisitos 3.5 y 3.6 (relacionados con la gestión de claves de encriptación) también aplican.
    Para darte una respuesta más ajustada, me vendría bien que me cuentes en dónde estarán guardados los datos (un archivo, una base de datos, etc.) y la razón por la cual se requieren esos datos en claro.
    Saludos,
    David

    en respuesta a: Información sobre implementacion de MPOS #54319
    David Acosta
    Participante

    Buenas tardes:

    La respuesta a tus preguntas es un poco complicada, pero trataré de simplificarla lo máximo posible.

    Antes que nada, es importante tener en cuenta los siguientes criterios:
    – El hardware que se va a emplear en la solución mPOS deberá estar aprobado bajo el estándar PCI PTS POI y solamente se podrán usar los modelos y las versiones de firmware homologadas. La lista de dispositivos la podrás encontrar aquí: https://www.pcisecuritystandards.org/assessors_and_solutions/pin_transaction_devices?agree=true
    – Los comercios que hagan uso de esta solución deberán cumplir con los requerimientos de los cuestionarios de autoevaluación SAQ B (si la conexión se realiza vía RPTC) o SAQ B-IP (si la conexión es vía GRPS/GSM/IP).

    Respecto a las preguntas, el dispositivo capturará los datos de la tarjeta (vía contactless, banda magnética, chip EMV) y los datos del PIN. A grandes rasgos, esas claves que te están pidiendo (Master Key / Session Key (working key)) son las claves que empleará el dispositivo para encriptar esos datos. Hay que tener en cuenta que el uso de estas claves (por ejemplo, para proteger el PIN) están sujetas al cumplimiento del estándar PCI PIN (https://www.pcihispano.com/que-es-pci-pin/).

    Para no complicarte más el asunto, todos estos temas derivados de la gestión de claves de encriptación te los debe solucionar tu adqquiriente o la pasarela de pago que los dispositivos vayan a usar. Igualmente, la integración del dispositivo con el adquiriente/pasarela (XML, ISO8583, JSON, SOAP) depende de cada proveedor…

    En términos de desarrollo de la aplicación, revisa estos artículos que te pueden ser útiles:

    ISACA publica una guía de seguridad en pagos móviles (y otros documentos interesantes): https://www.pcihispano.com/isaca-publica-una-guia-acerca-de-seguridad-en-pagos-moviles-y-otros-documentos-interesantes/
    El PCI SSC actualiza las guías de seguridad para la aceptación de pagos con móviles https://www.pcihispano.com/el-pci-ssc-actualiza-las-guias-de-seguridad-para-la-aceptacion-de-pagos-con-moviles/
    PCI DSS en aplicaciones de pago para smartphone https://www.pcihispano.com/pci-dss-en-aplicaciones-de-pago-para-smartphone/

    Espero que esta información te sea útil.

    en respuesta a: Antivirus Linux #54317
    David Acosta
    Participante

    Hola Paco:

    Tal y como lo comentaba arriba Max, esos artículos te darán una visión global del uso de soluciones Open Source para el cumplimiento con el requerimiento 5 (antimalware).

    El uso de ClamAV (https://www.clamav.net/) tanto para Windows como para GNU/Linux es aceptable desde el punto de vista del PCI SSC, siempre y cuando se configure de acuerdo con lo que pide el requerimiento 5:
    – Mantener la solución actualizada (tanto a nivel de aplicación como de firmas) usando freshclam
    – Configurar los escaneos periódicos usando clamscan + una entrada en el crontab (por ejemplo)
    – Configurar los escaneos On-Access (https://www.clamav.net/documents/on-access-scanning)
    – Configurar los registros de eventos (https://www.clearos.com/clearfoundation/social/community/clamscan-log-how-to-enable)
    Una guía más completa la podrás encontrar aquí: https://linux-audit.com/using-clamav-for-linux-pci-dss-requirement-5-malware-and-anti-virus/

    Respecto a Ansible, ¡por su puesto que lo puedes usar! El problema con estas herramientas radica en que, dependiendo de su ubicación en la red y de la forma en la cual despliegan los cambios en el entorno PCI DSS, pueden estar fuera o dentro del alcance de cumplimiento…

    Espero que esta información te sirva.

    en respuesta a: PCI DSS cómo requisito obligatorio para PCI PIN #54021
    David Acosta
    Participante

    Hola Rubén:

    Respecto a tu pregunta, comentar que el estándar PCI PIN está vinculado expresamente a los datos del PIN/PIN block en transacciones presenciales (POS/ATM). El cumplimiento con PCI DSS en un entorno de procesamiento de PIN/PIN block no es un prerrequisito de PCI PIN.

    No obstante, si miramos los criterios de aplicabilidad de PCI DSS nos daremos cuenta de que si hay PIN/PIN blocks, PCI DSS aplica:

    PCI DSS applicability

    Por otro lado, generalmente en transacciones presenciales en las que el PIN/PIN block está involucrado, también lo estará el PAN asociado a la tarjeta vinculada a esa transacción. Esto quiere decir que si tienes datos del titular de tarjeta y datos sensibles de autenticación, tanto PCI DSS como PCI PIN aplican, al margen de que explícitamente no se indique su necesidad en forma de requerimiento/prerrequisito.

    Por otro lado, estos estándares no son excluyentes (si tengo PCI DSS no aplica PCI PIN o viceversa), ya que están enfocados en la protección de datos diferentes, por lo que es necesario tener ambos conjuntos de controles de acuerdo con lo que indiquen las marcas de pago o los adquirientes.

    Espero que esta información te sirva.

    en respuesta a: Análisis de Vulnerbailidades 11.2 #53619
    David Acosta
    Participante

    Hola David:

    Respecto a tu pregunta, varias aclaraciones:

    1) El hecho de usar una solución de encriptación de extremo a extremo (P2PE o E2EE como SNCP en España) no implica que de forma automática estés exento de cumplir con PCI DSS. Incluso, en el mejor escenario que sería una solución P2PE homologada, el comercio debe rellenar un cuestionario de autoevaluación vinculado con este canal (SAQ P2PE), focalizado en la protección física de los dispositivos de pago. Para el caso del SNCP en España, es diferente, ya que SNCP no es una solución homologada por el PCI SSC y por lo general los bancos adquirientes recomiendan presentar un SAQ B-IP o un «cuestionario simplificado» provisto por RedSys. Puedes encontrar más información en estos artículos:
    – ¿Qué es SNCP (Sistema Nacional de Cifrado de Pistas)? https://www.pcihispano.com/que-es-sncp-sistema-nacional-de-cifrado-de-pistas/
    – Todo lo que siempre has querido saber acerca de los SAQ (Cuestionarios de Auto-evaluación) de PCI DSS v3.2.1 (Incluye comparativo en Excel de los tipos de SAQ) https://www.pcihispano.com/todo-lo-que-siempre-ha-querido-saber-acerca-de-los-saq-cuestionarios-de-auto-evaluacion/

    2) En el caso de plataformas de comercio electrónico integradas con proveedores de pago a través de un iFrame o de una redirección, el comercio debe reportar su cumplimiento con PCI DSS a través de un SAQ A (22 controles). Más información aquí:
    – ¿Quieres poner en marcha o tienes una tienda online? Sigue estos consejos para cumplir con PCI DSS https://www.pcihispano.com/quieres-poner-en-marcha-o-tienes-una-tienda-online-sigue-estos-consejos-para-cumplir-con-pci-dss/

    Saludos,

    David Acosta

    en respuesta a: tarjetas 3ds #53495
    David Acosta
    Participante

    Hola Jordi:
    1) La activación de la funcionalidad de 3DS se realiza directamente por el banco emisor. No obstante, los comercios y los centros autorizadores pueden optar por cambiar esta funcionalidad en función del riesgo que quieran asumir. En el artículo «¿Qué es PCI 3DS?» (https://www.pcihispano.com/que-es-3d-secure-3ds-y-por-que-es-tan-importante-para-la-proteccion-de-transacciones-en-internet/) podrás encontrar más información acerca de cómo funciona este modelo de autenticación reforzada.
    2) La implementación de 3DS se realiza empleando la especificación de EMV 3DS (versión 2) y no viene dado por restricciones geográficas, aunque puede servir para cubrir requerimientos legales, como PSD2 en Europa. Todo depende del banco emisor.
    3) 3DS (Three-Domain Secure) define la interacción entre los tres dominios implicados en la transacción (comercio/adquiriente, emisor e interoperabilidad) incluyendo los tres componentes básicos: 3DS Server (3DSS), Directory Server (DS) y Access Control Server (ACS). Cuando una transacción no presencial (comercio electrónico) se inicia, el comercio contacta al 3DS Server, que a su vez envía la transacción al DS, que identifica el emisor de la tarjeta y enruta la petición hacia él. El emisor de la tarjeta (empleando el ACS) identifica si la tarjeta tiene activado 3DS y procede con la solicitud del elemento de autenticación adicional (Cardholder Verification Method).
    Una explicación gráfica de este flujo la podrás encontrar aquí: https://www.visa.ca/dam/VCOM/regional/na/canada/security/security-documents/3ds-2-0-infographic.pdf
    Saludos,
    David

    en respuesta a: Id transacción adyen #53359
    David Acosta
    Participante

    Hola:
    Mientras que la información de identificación de la transacción no contenga el dato del PAN en claro no se requiere el cumplimiento con PCI DSS. En el caso de Adyen, este dato (transaction ID) se encuentra fuera del alcance de cumplimiento de PCI DSS.

    en respuesta a: Visualización de datos de una tarjeta prepaid #52913
    David Acosta
    Participante

    Hola Ericka:
    Respecto a tu pregunta, la respuesta depende del tipo de tarjeta prepago y su funcionamiento.
    Hay algunas tarjetas prepago que son de un único uso (son desactivadas después de la primera autorización) o de múltiples usos. Igualmente, hay tarjetas prepago que vienen desactivadas por defecto y otras que están activas cuando se le entregan al titular de la tarjeta (o tarjetahabiente).
    Hay que tener en cuenta que el objetivo de PCI DSS es proteger los datos de la tarjeta (sobre todo el PAN) para evitar fraudes. Si se trata de una tarjeta de un único uso, el riesgo de fraude está relativamente controlado (si un atacante obtiene esos datos, ya no los puede usar para transacciones posteriores). No obstante, en el caso de tarjetas multiuso, el riesgo de fraude sí que está latente.
    Igual en las tarjetas desactivadas. Mientras que la tarjeta permanezca desactivada no hay riesgo de fraude, pero en cuanto se active, se deben implementar controles para prevenir que sea comprometida.
    Al respecto, puedes consultar más información en este webinar de MasterCard: https://event.webcasts.com/viewer/event.jsp?ei=1116927
    Por otro lado, respecto a la visualización de datos, la aplicación que permite la visualización de los datos de la tarjeta debería cumplir con una serie de controles adicionales para evitar que los datos sean comprometidos o almacenados de forma insegura. Puedes usar como referencia esta FAQ del PCI SSC: https://pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/Can-the-full-credit-card-number-be-displayed-within-a-browser-window
    Espero que esta información te sirva.
    David

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