Respuestas de foro creadas

Viendo 15 entradas - de la 16 a la 30 (de un total de 257)
  • Autor
    Entradas
  • en respuesta a: Evaluación de Riesgos #52844
    David Acosta
    Participante

    Hola Marcia:
    De acuerdo con el requerimiento 12.2, el análisis de riesgos se debe realizar, al menos, una vez al año y después de implementar cambios significativos en el entorno (adquisiciones, fusiones o reubicaciones, etc.). No obstante, hay que tener en cuenta que el cálculo del nivel de riesgo de un activo viene dado por la interacción entre diversas variables como los activos, las amenazas, las vulnerabilidades, el impacto, la frecuencia (probabilidad), etc. Si asumimos que los activos no han cambiado en un año, las amenazas y vulnerabilidades seguro que sí, al igual que la frecuencia. Por eso, el ejercicio de evaluación de riesgos debe ser periódico, para garantizar que todas estas variables son analizadas en su contexto actual.
    Te pongo algunos ejemplos: ramsonware, ataques de día cero, la pandemia de COVIT-19, los ataques actuales a pagos de comercio electrónico, etc. Todos estos han aumentado respecto al año anterior y seguro que algunos ni siquiera se consideraron (como COVIT-19 y su impacto en la empresa).
    Por ello, el análisis de riesgos debe ser realizado anualmente así los activos no hayan cambiado.
    Finalmente, mi sugerencia es asumir la realización del análisis de riesgos como un ejercicio preventivo frente a potenciales problemas futuros y no como una simple acción burocrática para cumplir con el estándar. El valor de los análisis de riesgos han salvado a miles de empresas, permitiendo que se preparen ante eventos inciertos.
    Hace algunos años escribí un artículo relacionado con análisis de riesgos en ISACA Journal, que puedes leer aquí si te interesa ese tema: https://www.isaca.org/resources/isaca-journal/issues/2016/volume-2/ataraxia-and-premeditation-as-elements-of-judgment-in-the-risk-analysis-process

    en respuesta a: rechazos de pagos con tarjeta #52664
    David Acosta
    Participante

    Hola Jordi:
    Está claro que los procesadores de pago, los emisores y los adquirientes te cobrarán por cada transacción (correcta o inválida) que procesen. En ese sentido, si dentro de tu entorno implementas una serie de controles técnicos que sirvan como filtro frente a transacciones sospechosas o ya conocidas como fraudulentas, la cantidad de peticiones de autorización que enviarás será menor y de más calidad y, por ende, los costes que pagues también serán más bajos.
    En ese sentido, mi sugerencia es que revises el artículo «Breve análisis de 9 técnicas para la minimización del fraude en transacciones de comercio electrónico» https://www.pcihispano.com/breve-analisis-de-9-tecnicas-para-la-minimizacion-del-fraude-en-transacciones-de-comercio-electronico/ en donde enumero múltiples técnicas que se pueden implementar para gestionar este tema (uso de listas blancas, negras y grises, identificación dígital y análiss de comportamiento, etc,). Revísalo y me dices qué te parece.
    Muchas empresas dedicadas a medios de pago implementan este tipo de soluciones antifraude para controlar las potenciales pérdidas financieras. Los expertos en este tipo de controles suelen ser las empresas que ofrecen contenido para adultos, ya que suelen ser la primera opción de los atacantes para hacer una transacción peqeña y comprobar si la tarjeta es válida o no.
    Por otro lado, en el caso de una tarjeta robada o perdida, el único que te puede confirmar este problema es el banco emisor, por lo que no hay otra alternativa que enviar la transacción y esperar a que el banco la acepte o la rechace con base en sus propios procesos de atención al cliente.
    Espero que esta información te sirva.

    en respuesta a: Procesamiento de pagos con tarjetas #52574
    David Acosta
    Participante

    Hola Jordi:
    Muchas gracias por tus amables palabras.
    Para hacer la explicación un poco más gráfica emplearemos el ejemplo de España.
    Imaginemos un datáfono del Banco Sabadell que lee una tarjeta de La Caixa. En ese caso, la transacción se tiene que enviar desde el adquiriente (Banco Sabadell) a La Caixa (Emisor). Esto lo hace a través de RedSys (centro autorizador). Es RedSys quien hace la conexión entre los dos bancos (adquiriente y emisor) para que la transacción se pueda autorizar. Aquí, obviamente, hay unas tasas que son imputables al usuario (sobre todo en transacciones con cajeros automáticos).
    Ahora, imaginemos que el mismo datáfono del Banco Sabadell lee una tarjeta VISA emitida por un banco de Estados Unidos. Esta transacción va a RedSys y de RedSys a VISA, quien a su vez conecta con el banco de Estados Unidos para hacer la autorización. En este otro caso, también hay tasas y – además – se cobra por el cambio de divisa (Dólares a Euros).
    Como ves, hay centros autorizadores (o pasarelas de pago) que conectan los bancos locales y cuando la transacción sale de su entorno, se conecta con las redes de las marcas para la conexión con el emisor.
    Ahora bien, por el tema de los costes, esto es otro tema. Cada marca tiene sus políticas y cada banco y pasarela de pago también. No sé hasta qué punto eso está regulado (supongo que en España por el Banco de España), pero eso ya está fuera de mi alcance. Si quieres conocer estos valores, tendrías que hablar con un banco.
    Espero que esto te sirva.

    en respuesta a: Vulnerabilidades en mi servidor web #52571
    David Acosta
    Participante

    Hola Jhonny:
    Tienes que configurar el conector HTTPS (HTTPS Connector) para indicarle los conjuntos de cifrado robustos y remover los débiles. En este caso, esto se realiza con el atributo «cipher-suite».
    Aquí encontrarás la documentación oficial: https://docs.jboss.org/jbossweb/7.0.x/config/ssl.html
    Aquí tienes algunos ejemplos: https://discussions.qualys.com/thread/18078-jboss-eap-601-cipher-suite-configuration-not-working-as-expected-at-all
    Hay que tener en cuenta varias cosas adicionales:
    – Debes tener JDK 1.8 o superior
    – Debes tener configurado TLS 1.1 o superior
    – Debes remover todos los conjuntos de cifrado que contengan MD5, SHA-1, DES o algoritmos débiles (https://www.pcihispano.com/que-algoritmos-criptograficos-se-deben-emplear-para-cumplir-con-pci-dss/).
    Al finalizar, puedes hacer pruebas empleando cualquiera de las herramientas mencionadas aqui https://www.pcihispano.com/revisa-si-la-configuracion-de-tls-1-2-de-tu-sitio-web-es-correcta-con-estas-herramientas/
    Espero que esto te sirva.

    en respuesta a: Procesamiento de pagos con tarjetas #52450
    David Acosta
    Participante

    Hola Jordi:
    Gracias por tu comentario.
    Hace ya varios años publiqué el artículo «¿Alguna vez te has preguntado por dónde pasan los datos de tu tarjeta cuando realizas una compra? Aquí está la respuesta» (https://www.pcihispano.com/alguna-vez-te-has-preguntado-por-donde-pasan-los-datos-de-tu-tarjeta-cuando-realizas-una-compra-aqui-esta-la-respuesta/) en donde describo de forma general cómo se procesan los pagos con tarjeta. En términos generales, hay tres fases: autorización, conciliación y liquidación. Las redes de las marcas (VISA, MasterCard, AMEX, Discover y JCB) actúan de forma activa en todo el proceso. Su valor agregado es la conectividad entre el adquiriente y el emisor. En transacciones dentro de un misma zona geográfica esto es muy simple, pero en transacciones «crossborder» en el que los pagos se realizan con tarjetas de un banco de otro país, esto es muy importante.
    Échale un vistazo al artículo y si tienes más dudas, aquí estaremos.

    en respuesta a: Vulnerabilidades en mi servidor web #52449
    David Acosta
    Participante

    Hola Jhonny:
    Te he dejado mi respuesta en tu comentario del artículo. La copio aquí:
    El primer paso es identificar qué tipo de servidor web estás utilizando (Apache, Ngnix, IIS, etc.) y con base en ello, modificar el archivo de configuración en el que se le indica a este servidor qué conjuntos de cifrado debe utilizar. En el mismo reporte del escaneo ASV te debería indicar el tipo de servidor web que usas. Luego, ve a https://ssl-config.mozilla.org/, escoge el tipo de servidor, elige la configuración «Intermediate» y remplaza la lista de conjuntos de cifrado (cipher suites) con la que te aparece ahí.
    Espero que estas indicaciones te sirvan.

    en respuesta a: QSA para un ISO 27001 Lead Auditor #52371
    David Acosta
    Participante

    Si, totalmente de acuerdo contigo. Es mejor ir poco a poco.

    en respuesta a: PCI-DSS para una empresa con un ERP #52370
    David Acosta
    Participante

    Buenas tardes:
    Para aclararnos, voy a referenciar a la fuente de confianza 🙂 el PCI SSC:

    For information about protecting different elements of cardholder data (CHD), please refer to the tables provided in the “PCI DSS Applicability Information” section in the PCI DSS. The tables illustrates that, if cardholder name, service code, and/or expiration date are stored, processed or transmitted with the PAN, or are otherwise present in the cardholder data environment, they must be protected in accordance with applicable PCI DSS requirements.

    This means that all applicable PCI DSS requirements, such as firewalls, patches, anti-virus, access controls, policies and procedures, etc., must be applied for protection of those cardholder data elements. However, only the PAN itself must be rendered unreadable in accordance with Requirement 3.4.

    If these other elements of cardholder data (that is, cardholder name, expiry date and/or service code) are present without any PAN, then PCI DSS would not apply to those elements.

    ¿Qué quiere decir esto?:

    • Si el PAN se procesa, se almacena y/o se transmite, entonces hay que cumplir con PCI DSS.
    • Si el PAN se almacena, se procesa y/o se transmite con el nombre del titular, el código de servicio y/o la fecha de expiración, entonces PCI DSS aplica a TODOS estos elementos, con la excepción que el 3.4 solamente debe cubrir al PAN.
    • Si solamente se tiene el nombre del titular, la fecha de expiración y/o el código de servicio SIN PAN entonces no se requiere el cumplimiento con PCI DSS.

    Espero que esta información te sea útil.

    en respuesta a: QSA para un ISO 27001 Lead Auditor #52281
    David Acosta
    Participante

    Buenas tardes:
    Si el objetivo es ofrecer servicios de PCI DSS como empresa, un PCI ISA solamente puede efectuar evaluaciones de cumplimiento para la empresa para la que trabaja y que requiere demostrar cumplimiento con PCI DSS, no para otras empresas externas. En ese caso, se requiere exclusivamente de un asesor QSA.
    Por otro lado, un profesional PCIP sí que puede ofrecer servicios a empresas externas para implementación (no para evaluación formal), ya que esta certificación no está vinculada con el empleador sino con el profesional.

    en respuesta a: PCI-DSS para una empresa con un ERP #52280
    David Acosta
    Participante

    Buenas tardes:
    En este caso, es muy importante tener presente que la aplicabilidad de PCI DSS radica en el PAN (el número de cuenta principal es el factor que define los datos del titular de la tarjeta). Si el nombre del titular de tarjeta, el código de servicio y/o la fecha de vencimiento se almacenan, procesan o transmiten con el PAN (número de cuenta principal) o se encuentran presentes de algún otro modo en el entorno de datos del titular de la tarjeta, se deben proteger de conformidad con los requisitos aplicables de PCI DSS.
    No obstante, si solo se almacena la fecha de expiración o los 4 últimos dígitos del PAN, entonces no es necesario el cumplimiento con PCI DSS en aquellos elementos del sistema que almacenen estos datos.
    Sin embargo, hay que realizar un análisis exhaustivo del entorno, ya que si se tiene acceso a la fecha de expiración o a los 4 últimos dígitos de la tarjeta, es muy probable que en algún flujo operativo se obtengan los datos originales de la tarjeta (PAN completo y fecha de expiración) y luego se «saniticen» (4 últimos dígitos + fecha de expiración). En ese caso, el sistema que tiene acceso al PAN completo sí que debe cumplir con PCI DSS.
    Ejemplo: un servidor web que capture datos de tarjetas en un formulario y luego almacene en logs o bases de datos la fecha de expiración y los últimos 4 dígitos del PAN. En este caso, los logs y las bases de datos están fuera del alcance, pero el servidor web y el formulario que captura los datos completos de de la tarjeta no.
    Saludos,
    David

    en respuesta a: Certificación ISA #52279
    David Acosta
    Participante

    Hola a todos:
    Después de casi 4 años desde la última respuesta, considero que la decisión de ir por un ISA o por un QSA depende de la política de la organización respecto al cumplimiento normativo y a las actividades de auditoría. Obviamente, ambos escenarios (ISA o QSA) son válidos, pero, bajo mi punto de vista, trabajar con un asesor QSA le otorga a la empresa que va a ejecutar una evaluación formal de cumplimiento:
    – Un criterio independiente,
    – Posibilidades de optimización del cumplimiento gracias a la experiencia del QSA en múltiples entornos similares,
    – Posibilidad de cambiar de asesor cuando la empresa lo considere necesario (¿Cuáles son las ventajas de un programa de rotación periódica del asesor o empresa QSA?).
    Elementos que potencialmente un ISA no podría aportar.
    Nuevamente, todo depende del criterio de la empresa que debe cumplir con PCI DSS.
    Otra cosa es una empresa que ofrezca servicios de evaluación de cumplimiento de PCI DSS. En este caso, un ISA no aplica, ya que este rol solamente puede efectuar evaluaciones de cumplimiento en la empresa de la cual es empleado.

    en respuesta a: Dispositivos con aprobación caducada #52278
    David Acosta
    Participante

    Buenas tardes:

    • Respecto a los dispositivos (datáfonos) con la certificación PCI PTS caducada, hace poco más de un año publiqué un artículo al respecto (¿Tu empresa usa datáfonos y otros dispositivos de captura de PIN? Entonces esta información te interesa). En este caso, cada una de las marcas define su propia política respecto al uso de dispositivos caducados.
      En el caso de VISA, se han definido las siguientes fechas:
      VISA PED Sunset dates
      Esto quiere decir que si tienes dispositivos PCI PTS version 1 y 2 (y próximamente 3), los podrás seguir usando durante un tiempo limitado pero no puedes comprar dispositivos nuevos de ese mismo modelo.
    • Respecto a la pregunta de key blocks, la gestión de claves de encriptación para la protección del PIN (tanto en dispositivos de punto de interacción (POI) como POS y ATMs y en la conexión con entidades externas) se realiza en el HSM. Por lo tanto, es en el HSM en donde se puede validar una correcta implementación de esa funcionalidad. Igualmente, dependiendo del fabricante del HSM se pueden encontrar diferentes variantes de key blocks (Atalla, Thales, etc.). Mi sugerencia en este sentido es usar ANSI TR-31, que ofrece compatibilidad entre HSMs de diferentes fabricantes.

    Espero que esta información te sea de utilidad.

    Saludos,

    David

    en respuesta a: PCI PIN – HMS en la nube? #52276
    David Acosta
    Participante

    Hola Nicolás:
    Con este tema de HSM en cloud todo era cuestión de tiempo. Mi última respuesta es de poco menos de un año y en aquel entonces no había proveedores de cloud que ofrecieran HSM certificados como PCI HSM o FIPS 140-2 Level 3 para el entorno financiero (recordad que desde el punto de vista operativo hay dos tipos de HSMs: los de propósito general y los orientados a transacciones de pago).
    Ahora mismo, por mi experiencia en este área, he identificado dos proveedores muy interesantes de este tipo de servicios:
    – MyHSM (https://myhsm.com/)
    – Utimaco HSM-as-a-Service (https://hsm.utimaco.com/products-hardware-security-modules/form-factor/cloud-hsm-as-a-service/)
    Ambos ofrecen dispositivos HSM para integrar en un entorno PCI PIN y cuentan con servicios de valor agregado como la gestión de componentes de claves, el uso de custodios a nombre del cliente, la operación y administración del dispositivo y la seguridad física del entorno.
    Espero que esto os sirva.
    David

    en respuesta a: Si uso token de PCI para llamar tengo que ser PCI ? #52192
    David Acosta
    Participante

    Hola Alberto:
    Hay que tener en cuenta que un flujod e tokenización está compuesto de un «camino de ida» y un «camino de vuelta«.
    En el «camino de ida» se supone que se capturan los datos de la tarjeta del titular y se envían al centro autorizador. En este caso, este «camino de ida» sí que debe cumplir con PCI DSS porque interactúa directa o indirectamente con el dato del PAN.
    Ahora bien, si hay tokenización, tenemos un «camino de vuelta» en el cual el proveedor del servicio de tokenización te devuelve un token. Al ser un token un dato anonimizado del cual no se puede extraer directamente la información del PAN, este dato no supone ningún riesgo y está fuera del alcance del cumplimiento de PCI DSS.
    De acuerdo con tu pregunta, si más Adelante quieres usar ese token para realizar pagos en un click (One Click Payments – OCP) o pagos recurrentes, entonces ese canal y esos procesos están fuera del alcance de PCI DSS.
    Revisa estos dos artículos que te pueden servir como referencia:
    El concepto de tokenización y su aplicabilidad en PCI DSS
    Pagos recurrentes y pagos en un clic: ¿Qué son, qué beneficios aportan, qué riesgos implican y cómo se pueden gestionar de forma segura?
    Saludos,
    David

    en respuesta a: QSA para un ISO 27001 Lead Auditor #52187
    David Acosta
    Participante

    Hola Antonio:
    Para realizar certificaciones PCI DSS requieres que la compañía esté registrada como QSA Company (QSAC) y que se cumplan una serie de requisitos (pago de seguros, pago de anualidades, etc.). Hecho esto, esa compañía puede proceder a enviar a cursos a sus empleados, siempre y cuando tengan como mínimo 2 certificaciones de seguridad y experiencia en medios de pago, entre otros temas. El primer curso es presencial y los siguientes son online, pero igualmente se requiere del pago de una anualidad por cada empleado certificado. Los costes son muy altos, pero también es muy alta la responsabilidad en la ejecución de estas evaluaciones formales.
    No obstante, nada te limita para que puedas efectuar implementaciones y/o adecuaciones del estándar. Solamente las evaluaciones formales de cumplimiento (erróneamente llamadas «auditorías») pueden ser ejecutadas por un QSA.
    En ese caso, un perfil como PCI Professional te vendría muy bien para tener un conocimiento general del estándar y de su aplicabilidad. Échale un vistazo a este artículo: ¿Quieres certificarte como PCI Professional (PCIP)™? Esta información te interesa
    Saludos,
    David

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