De acuerdo a las políticas de las franquicias de las tarjetas Visa, Mastercard, American Express, Diners, Discover, JCB, UnionPay, entre otras, es requerido, siempre, desde $0, tener un certificado de cumplimiento PCI DSS nivel 2, al día de hoy, los requerimientos para los niveles 1, 2 y 3 son iguales, que es PCI DSS SAQ 4.0 + AOC + ASV
Si requieres ayuda, revisa el final de este tutorial.
Visa Colombia:
Credibanco contrato:
Leer toda la documentación de PCI es al menos 2100 página (Documentación + Formularios), lo que requiere unas 72 horas de lectura, aquí te lo presentamos tan simple como posible. Hacerlo sin ayuda, es al menos 1 mes, con este tutorial podría ser desde 2 días.
Lo primero es realizar el escaneo de un proveedor aprobado, nosotros te recomendamos Comodo HackerGuardian Sectigo $86.9 USD / Año https://comodosslstore.com/hacker-guardian-pci-scan-control-center.aspx
Si vas a usar el scanner de Sectigo, debes de agregar el hostname, es decir, el dominio donde los usuarios ingresan las tarjetas:
Luego agregar la IP del servidor, si usas un CDN, debes agregar la IP donde está el servicio:
Luego inicia tu primer scan
Por IP
Y por hostname:
Donde dice Schedule for later, te recomiendo hacerlo diariamente, idealmente iniciando tipo 3 AM (Tarda unas 3 horas), para IP
Y para hostname:
Debería verse así:
Cuando hagas el primer scan, debes revisar en vulnerabilities y asegurarte que no haya ninguna relativa a PCI
Es posible que aparezcan vulnerabilidades que debas solucionar, debes analizar muy técnicamente si es algo a solucionar y solucionarlo, o si es un falso positivo, reportarlo, tardan 1 día hábil en aprobar. Aquí una lista de todos los que hemos reportado, el 100% de los que se han reportado, han sido aprobados:
Te pongo ejemplos de los textos que hemos usados al reportar falsos positivos:
1. [38868] - OpenSSH Privilege Escalation Vulnerability
> Redhat has fixed it - CVE-2021-41617 upstream fix (#2008885) https://bugzilla.redhat.com/show_bug.cgi?id=2008291 in the installed openssh-8.0p1-13.el8
2. [38867] - OpenSSH Double Free Vulnerability
> There is a false positive based on Redhat https://bugzilla.redhat.com/show_bug.cgi?id=1935055 and there is a confirmation that the installed version is openssh-8.0p1-13.el8
3. [86310] - Web Server Predictable Session ID Vulnerability
The Software that is generating the cookies with the name lsws_uid and lsws_pass is LiteSpeed Web Server Enterprise v6.0.11 ( https://www.litespeedtech.com/products/litespeed-web-server )
The PCI scanner is assuming the value 'deleted' is the generated random value for a session cookie. In fact, it is the way for Litespeed to delete a cookie, overwriting its value with a 'deleted' string.
You can verify in the open-Source version of Litespeed that deleted value is only used to track a deleted cookie and not to identify an authenticated user:
https://github.com/litespeedtech/openlitespeed/blob/eb6486bab881841680cca854e861617a9139a432/src/http/httpreq.cpp#L3245
Session cookies are generated using safe random regenerators as seen here: https://github.com/litespeedtech/openlitespeed/blob/eb6486bab881841680cca854e861617a9139a432/dist/admin/html.open/lib/CAuthorizer.php#L271
Then, this is a false positive. I request you to ignore it.
4. [38773] - OpenSSH Integer overflow Vulnerability
Hello, About: CVE-2019-16905, RedHat statement: The versions of OpenSSH package shipped with Red Hat products, do not enable support for XMSS and therefore are not affected by this flaw. You can check here: https://access.redhat.com/security/cve/cve-2019-16905
We confirm we have not enabled the use XMSS keys for SSH.
dnf info openssh
This system is receiving updates from CloudLinux Network server.
Last metadata expiration check: 0:23:45 ago on Wed 05 Jan 2022 01:12:09 PM -05.
Installed Packages
Name : openssh
Version : 8.0p1
Release : 10.el8
Architecture : x86_64
Size : 1.8 M
Source : openssh-8.0p1-10.el8.src.rpm
Repository : @System
From repo : baseos
CloudLinux statement:
We followed our upstream RHEL in order to provide any updates related to OpenSSH / OpenSSL and similar packages.
So all the information provided in the https://access.redhat.com/security/cve/cve-2019-16905 is also related to CloudLinux 6,7,8 (RHEL 6,7,8).
Luego de que ya no tengas ninguna vulnerabilidad PCI, solicitas a Qualys que firme el scan:
Luego que te confirmen vía email que fue firmado/aprobado (1 día hábil)
Ahora, configure los bancos a los que les vas a reportar, para el caso de Colombia, es Incocredito la entidad que investiga el fraude (El Banco es el que te sanciona), asegúrate que todos los campos estén diligenciados:
Luego en esta sección le das enviar al reporte:
Debe verse así:
El reporte ejecutivo y el técnico lo descargas, probablemente lo debes enviar también a tu pasarela gateway (Por ejemplo, Credibanco, Redeban).
Esto lo debes hacer cada 90 días, pedir que firmen el scan que debe ser hecho el mismo día y enviarlo.
Si has llegado a este punto, ya tienes la mitad del trabajo hecho, ahora debes diligenciar el SAQ y AOC, esto es anual.
Verifica la versión actual en https://www.pcisecuritystandards.org/document_library/
Desde 31 marzo 2022 la versión de PCI DSS es 4.0, la versión 3.2.1 (de mayo 2018) se puede usar hasta 31 marzo 2024, para este ejemplo lo vamos a hacer con la 4.0
De la anterior URL descarga el documento "SAQ A-EP" en su versión en Docx y el "AOC SAQ A-EP" en su versión en Docx
Inicia a diligenciar el SAQ:
Indicamos que el único canal es ecommerce y no hay entidad que vaya a avalar/fimar.
Se explica cómo se hacen las transacciones por el website, una explicación de alto nivel del entorno y que se hace segmentación
Se indica que no aplica la certificación de alguna instalación física para PCI:
Se indica que no se usa algún producto PCI (Podría ser una terminal/datafono):
Se listan las pasarelas de pago y todo lo que implique tocar los datos de las tarjetas:
Antes de diligenciar la sección 2g que es un resumen del cumplimiento de los 12 puntos de PCI, vamos a continuar.
Se confirma en la sección 2h que este SAQ es apropiado para nosotros:
Ahora vamos a ir contestando cada uno de los requerimientos:
2.2.2 In place, ya que se cambian las contraseñas de cualquier acceso, tanto al recibir el acceso por primera vez como cada 60 días.
Vendor default accounts are managed as follows:
• If the vendor default account(s) will be used, the default password is changed per Requirement 8.3.6.
• If the vendor default account(s) will not be used, the account is removed or disabled.
3.1.1 Not Applicable, ya que todo se maneja electrónicamente, nada físico.
3.2.1 Not Applicable, ya que todo se maneja electrónicamente, nada físico.
6.3.1 In place, ya que, por ejemplo, estamos suscritos a las alertas de email de https://www.cisa.gov/uscert al igual que recibimos notificaciones de cada tweet de https://twitter.com/CVEnew/ para conocer las últimas vulnerabilidades, con su respectivo CVSS base score de 4.0 o más son consideradas críticas para buscarle solución inmediata en caso de tener algún software con una versión instalada vulnerable. Si no tiene aún un CVSS base score, la analizamos para determinar si existe la posibilidad que haya fuga o alteración de información para considerarla crítica.
6.3.3 In Place, ya que usamos Cloudlinux KernelCare para aplicar cada 4 horas parches en caliente al kernel que no requieren reinicio, adicional que configuramos para que dnf instale actualizaciones diariamente en forma automática.
6.4.3 In Place, El primer punto se implementa con Content-Security-Policy que un ejemplo puede ser
Content-Security-Policy: "upgrade-insecure-requests; frame-ancestors 'self'; default-src 'self";
Ahí te estas asegurando de intentar forzar el uso de https, solo permitir iframes del mismo website y solo permitir JavaScript del mismo website.
Para el segundo punto usa Subresource Integrity
Para el tercer punto, dice "justificación porque cada script es necesario" y en la definición de necesario de PCI dice "Lo estrictamente requerido para que el pago se complete", en ese orden Google Analytics u otros sistemas de tracking deberían estar deshabilitados en la página desde la que se hace la redirección a la pasarela, para hacer una redirección (HTTP) no se requiere JavaScript alguno, por lo que la lista de scripts termina siendo cero.
Así que para cumplir este punto solo asegúrate de agregar el HTTP header de CSP en la página de pago así
Content-Security-Policy: "upgrade-insecure-requests; frame-ancestors 'self'; default-src 'none";
Con esto, básicamente cumples los 3 puntos de este requerimiento, al no tener JavaScript alguno y por HTTP header CSP bloquear cualquiera que llegase a existir.
8.2.1 In Place, todos los usuarios que acceden a cualquier sistema requieren 2FA (Segundo factor de autenticación / Multifactor authentication) con una aplicación de generación de códigos basado en tiempo como Google Authenticator, lo cual hace requerido que cada persona se autentique con su propio usuario que tiene una ID única en el sistema.
8.2.2 In Place, No se usan ni se tiene permitido usar cuentas genéricas, todos los usuarios tienen su propio usar que requiere 2FA (Segundo factor de autenticación / Multifactor authentication) con una aplicación de generación de códigos basado en tiempo como Google Authenticator, lo cual hace requerido que cada persona se autentique con su propio usuario que tiene una ID única en el sistema y cada acción realizada se atribuye con seguridad a un usuario específico.
8.2.5 In Place, en las políticas está especificado revocar el acceso a cada usuario que ya no debería poder accesar, como, por ejemplo, la desvinculación a la empresa o reasignación a otro proyecto/área. Se puede conocer la lista de los usuarios, incluido la lista de usuarios con acceso revocado.
8.3.1 In Place. El sistema requiere email/contraseña/2FA, que es algo que you know (Usted sabe) (email/contraseña) y al que you have (Usted tiene) (2FA). Este requerimiento requiere solo uno, con email/contraseña/2FA, se obtienen 2.
8.3.5 In Place. El sistema no le envía contraseñas a los usuarios, le envía un link donde el usuario puede asignar su contraseña, así queda satisfecho este requerimiento.
8.3.6 El sistema requiere contraseñas que tengan al menos 16 caracteres, incluyendo al menos 1 mayúscula, 1 minúscula, 1 número y 1 simbolo.
8.3.7 In Place. El sistema guarda las ultimas 4 contraseñas usadas en forma "hashed". Un algoritmo recomendado es sha3-256 por su seguridad y velocidad. El sistema al usuario asignar una nueva contraseña verifica si coincide con una de las 4 últimas, de ser así, rechaza el cambio de contraseña.
8.3.9 In Placed. El requerimiento pide que, si solo se usa contraseña, se pida que estas se cambien cada 90 días, en nuestro caso se pide más que la contraseña, el 2FA, y adicional se forza el cambio de contraseña cada 60 días.
9.* Not Applicable. Todos los requerimientos del 9.4.* se marcan como Not Applicable ya que no se usa nada en físico/papel y menos para información relacionada con los datos de las tarjetas.
11.3.2 y 11.3.2.1 In Place. El scan trimestral fue lo que primero abordamos en este tutorial, por lo tanto, si se está haciendo cada 3 meses, sin dejar alguna vulnerabilidad de puntaje 4 o mayor, pidiendo que lo avalen/firmen y enviándolo a el Banco/pasarela/Incocredito, se marca como In Place estos dos requerimientos.
11.6.1 Not Applicable. Ya que se redirecciona a completar el pago en la pasarela, no se hace iframe.
12.8.1 In Place. Se tiene la lista de pasarelas con las que se tiene contrato y que tipo de servicio de usa de cada una.
12.8.2 In Place. Se tiene contratos por escrito con cada pasarela donde se hacen responsable de la información que ellos manejen.
12.8.3 In Placen. Se valida que la pasarela tenga PCI DSS nivel 1 SAQ D Proveedor antes de contratar sus servicios. Aquí se pueden consultar las pasarelas que tienen PCI según Visa:
https://www.visa.com/splisting/searchGrsp.do#
Aplicas un filtro así para ver las que tienen en Colombia:
Y a 2022-07-08 salen 20 resultados, de los cuales brindan servicios de pasarela son: Credibanco (desde 0% + $0 por transacción hasta $745 IVA Incluido), Evertec (Placetopay, hasta 3.5%), Kushki (Desde $4.76 millones / mes), Mercadopago (Hasta 3.29% + $900), Openpay (2.8% + $900), Redeban (hasta $915 por transacción), Pagosonline (Payu, hasta 3.49% + $800), Paymentez, Wipay. Wompi no está en esta lista de Visa y para el modelo gateway requiere "servicio de Aceptación de Pagos (Adquirencia)" de Bancolombia, lo que no lo hace apto para usarlo con cualquier banco.
12.8.4 Se valida anualmente que la pasarela cuente con PCI DSS nivel 1 SAQ D Proveedor.
12.10.1 Tenemos una política de respuesta a incidentes con todo lo descrito en este punto, que te la compartimos
Aquí diligenciamos el apéndice D, indicando la razón de los Not Applicable
Como todos los requerimientos requeridos fueron In Place, lo marcamos:
Confirmamos que tenemos presente que hicimos esto de acuerdo a las instrucciones y que mantendremos el cumplimiento en todo momento:
Lo relacionado con una entidad certificadora/avaladora lo dejamos vacío, ya que en este caso no hay, si se hacen más de 6 millones de transacciones por año se hace requerido la entidad certificadora/avaladora externa (el QSA)
Ahora debes hacer el AOC (Certificación de cumplimiento)
Diligenciamos los datos de contacto:
Ahora indicamos que el único canal de ventas es ecommerce
Explicamos el manejo a la información de tarjetas por el ecommerce:
Explicamos a alto nivel cual es el entorno y que hacemos segmentación
Indicamos que no hay alguna instalación física que esta certificación de PCI esté cubriendo:
Indicamos que no usamos algún PCI SSC
Indicamos las pasarelas que usamos y los servicios que usamos:
Marcamos los requerimientos según corresponda:
Ahora que ya tenemos la información del resumen, regresamos al SAQ A para diligenciar la misma tabla 2g y luego continuamos de nuevo en el AOC:
Procedemos a enviar a la pasarela de pago, al banco y Incocredito:
SAQ A
AOC
Scan firmado por la entidad avalada.
Nos aseguramos de mantener en cumplimiento en todo momento el PCI, la seguridad.
Esos documentos se deben enviar anualmente, verificando todo de nuevo y si hay una nueva versión de PCI DSS, esta fue con la 4.0 que salió en abril 2022
Algunas notas:
Si deseas ampliar los conocimientos técnicos que esto requiere, puedes revisar este documento donde Google Cloud describe ellos de que se encargan en cuanto a PCI y el usuario de que:
https://services.google.com/fh/files/misc/gcp_pci_shared_responsibility_matrix_aug_2021.pdf Está actualizando hasta PCI DSS 3.2.1 que es la inmediatamente anterior a la 4.0
En este documento dan pistas de las tecnologías requeridas para lograr algunos requerimientos de PCI, aunque el documento no fue pensando para las certificaciones que requiere un comercio, sino un implementador de 3D Secure, es una buena guía:
https://services.google.com/fh/files/misc/google_pci3ds_whitepaper_20210727.pdf
Si requieres asistencia para lograr PCI DSS lo mejor sería contactar a una empresa dedicada a ello como
https://gmsectec.com/es/servicios-de-seguridad/consultoria/ (Usado por Aper, Bold, Credibanco, Kushki (usado por Rappi), Payco, Payu, Redeban),
https://www.controlcase.com/certifications/pci-dss-certification/ (usado por peopletech.com.co y zonavirtual.com ),
https://www.iqcol.com/evaluacion-de-cumplimiento/ (Los únicos que solo dominan español - Usado por https://www.asnetsolutions.com/, http://www.cci-ltda.com/),
https://a-lign.com/compliance/pci-dss/ (Usado por Mercado Pago Colombia)
O para una asesoría de un Ingeniero de Software, a una tarifa de $80 USD / Hora o fracción, envía la solicitud a ticket@hostingfacil.co
Si usas el Hosting de Hostingfacil.co ya tienes asegurada la parte del scanner, ya que nosotros mismos tenemos PCI DSS 4.0 SAQ A + AOC + ASV como comercio.
