La mayoría de dichos cuestionarios solo han sido sometidos a pequeñas variaciones o ajustes, con el objetivo de reforzar las medidas de autenticación requeridas por los usuarios en dichos escenarios, proporcionar una mayor garantía a los comercios que externalizan parcialmente sus entornos de e-commerce, y simplificar los requerimientos de los comercios que utilizan soluciones de cifrado punto-a-punto certificadas por el PCI SSC (PCI P2PE).
No obstante, el SAQ que sin duda ha sufrido mayores cambios ha sido el SAQ A, con la inclusión de varios requerimientos del estándar PCI DSS que comentaremos a continuación.
Recordemos que dicho SAQ está orientado a entornos de pago con tarjeta no presenciales (e-commerce o entorno MOTO (mail-order/telephone-order)), que tienen todos sus procesos de pago externalizados a un proveedor, y que en ningún caso almacenan, procesan o transmiten datos de tarjeta en formato electrónico.
En el caso de que la externalización de los servicios de pago se dé en un e-commerce, y para que un comercio sea elegible para rellenar un SAQ A, debe de realizarse una redirección web directa a la web del proveedor, o bien una entrada de datos de tarjeta en el entorno del proveedor a través de un iFrame, ya que si se envían formularios de entrada de datos de tarjeta creados en la web del comercio con POST, o bien se utilizan formularios dinámicos generados con JavaScripts, el comercio debería rellenar un SAQ A EP, más restrictivo que un SAQ A.
Así pues, vemos a continuación los nuevos requerimientos que afectan a la versión 3.2 del SAQ A:
Requerimientos 2.1.a y 2.1.b, que obligan a cambiar los parámetros por defecto de un sistema, y a eliminar los usuarios por defecto del mismo antes de su instalación en un entorno PCI DSS.
Requerimientos 8.1.1 y 8.1.3, que solicitan el uso de usuarios nominales y únicos para todos los accesos al entorno, así como un estricto control de la eliminación o desactivación de dichos usuarios cuando su propietario finalice su función de negocio en el entorno de cumplimiento.
Requerimientos 8.2 y 8.2.3, por los cuales debe habilitarse una autenticación de como mínimo un factor para todos los accesos al CDE (Cardholder Data Environment), así como implantarse una correcta política de contraseñas para dichos accesos, forzando el uso de contraseñas de como mínimo 7 caracteres de longitud y complejidad en su generación.
Requerimiento 8.5, que prohíbe el uso de cuentas genéricas o compartidas para los usuarios existentes en el CDE, especialmente para fines administrativos.
Y finalmente, el Requerimiento 12.10.1, que requiere la definición de un plan de respuesta a incidentes formal en la entidad, para identificar y responder de manera adecuada a los posibles eventos maliciosos ocurridos en el CDE.
Como hemos podido observar, los comercios afectados por el SAQ A deberán implantar a partir de ahora nuevos requerimientos relativos al estándar PCI DSS, cosa que sin duda les traerá más de un dolor de cabeza. No obstante, seguro que una vez sean integrados a su negocio, los nuevos requerimientos proporcionaran un nivel de seguridad mucho más elevado a su CDE, que es lo que persigue el ecosistema de estándares del PCI SSC.
Referencias
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf
https://www.pcisecuritystandards.org/documents/PCI-DSS-v3_2-SAQ-A.pdf
https://blog.pcisecuritystandards.org/pci-dss-3.2-saqs
http://www.pcihispano.com/todo-lo-que-siempre-ha-querido-saber-acerca-de-los-saq-cuestionarios-de-auto-evaluacion/
www.visaeurope.com/media/pdf/processing%20e-commerce%20payments%20guide.pdf
Autor: Guillem Fàbregas - PCI QSA, PCIP, CISSP, CISA, CISM, CRISC, ISO 27001 L.A.
Departamento de Consultoría.
