Novedades PCI DSS v3.0 (Parte II): Mejores Prácticas hasta Julio de 2015

Siguiendo con la serie de artículos que analizan la nueva versión de PCI DSS, en esta segunda entrada del blog, se analizarán los nuevos requisitos añadidos que serán buenas prácticas hasta julio de 2015. Debido a las implicaciones que tiene la implantación de estos nuevos requisitos, el PCI SSC deja un año y medio a las empresas para implantarlos.

Estos nuevos requisitos los podemos agrupar en los siguientes apartados:
1. Nuevas vulnerabilidades a verificar en el desarrollo seguro de aplicaciones
Respecto al desarrollo seguro de aplicaciones, esta nueva versión añade dos vulnerabilidades nuevas a verificar antes de que el código pase a producción. La primera vulnerabilidad a verificar es el “manejo inseguro de datos sensibles en memoria”. Lo que se pretende es evitar que se produzcan robos de información por una mala gestión de los datos en memoria, pudiendo ser estos datos robados por diferentes canales, como, por ejemplo, si se accede a los datos en memoria debido a que éstos no se eliminan una vez ya no se utilizan (se libera el espacio en memoria pero el dato sigue estando en memoria), o se fuerza el error en memoria, recogiendo los datos volcados a fichero en disco.

Para proteger las aplicaciones de esta vulnerabilidad se recomienda no almacenar el dato en memoria si no es necesario (si no tenemos el dato, no nos lo pueden robar), borrar los datos una vez que no sean necesarios, o asociar el atributo “private” a estos datos en caso de utilizar programación orientada a objetos.

La segunda vulnerabilidad añadida es “pérdida de autenticación y gestión de sesiones”. Se debe verificar que las funciones relacionadas con la autenticación y gestión de sesiones se implantan correctamente para evitar que terceros puedan apropiarse de identificadores de sesión, contraseñas en claro, etc. con el objetivo de robar cuentas de usuarios.

Para evitar esta vulnerabilidad, algunas de las medidas que se recomiendan son almacenar las credenciales utilizando hash o cifrado, no mostrar los identificadores de sesión en la URL, forzar la caducidad de las sesiones, marcar los tokens de sesión (por ejemplo, cookies) como “seguro”, o enviar credenciales a través de conexiones TLS. En resumen, evitar la manipulación de los parámetros de sesión establecida.

2. Terminales punto de venta (TPV)
Posiblemente, los requisitos referentes a la seguridad física en TPVs atendidos o desatendidos serán de los que más impacto tengan en las organizaciones, y de los más costosos de implementar, en tiempo y recursos. Debido al creciente aumento de fraudes en dichos terminales, las organizaciones deben poner controles adicionales a los TPVs que permitan gestionarlos de forma segura. Se deberán inventariar todos los TPVs, incluyendo al menos la marca y modelo, la ubicación y el número de serie. Si no se sabe qué es lo que uno tiene, es complicado protegerlo.

Se deben establecer procedimientos para realizar revisiones periódicas de los TPVs, verificando que éstos no han sido manipulados, y no se han colocado skimmers u otro tipo de dispositivos que permitan capturar los datos de tarjeta.

Por último, se deberán desarrollar procedimientos para gestionar el mantenimiento de los TPVs. Es decir, se debe identificar a los proveedores que realizan el mantenimiento, evitando posibles ataques de ingeniería social, alertar a quien corresponda en caso de detectar comportamientos extraños de individuos alrededor del TPV o verificar que el reemplazo del TPV en su totalidad o alguna pieza ha sido autorizado previamente.

Además de establecer estos procedimientos, se deberán impartir formaciones a los empleados para que conozcan estos procedimientos, conozcan los posibles ataques que pueden sufrir los TPVs, y las situaciones en las que deben alertar a sus responsables.

3. Test de intrusión
Se debe desarrollar una metodología para la ejecución de tests de intrusión. Esta metodología, debe basarse en las buenas prácticas de la industria como por ejemplo, NIST SP800-115, Open Source Security Testing Methodology Manual (OSSTMM), OWASP (para aplicaciones web), etc., tener en cuenta todo el entorno de datos de tarjeta, validar la segmentación, revisar las vulnerabilidades que hayan aparecido en los últimos 12 meses, especificar el periodo de retención de los resultados de los tests de intrusión y las actividades derivadas del plan de remediación, y al menos verificar que los sistemas no son vulnerables a las vulnerabilidades que aparecen en apartado 6.5.x (inyecciones SQL, buffer overflow, etc.).

Aunque se mantiene que se debe hacer al menos una vez al año, o tras un cambio significativo, un test de intrusión interno y otro externo a nivel de aplicación y a nivel de red, sí se especifica que para este último se deben evaluar todos los componentes que soportan la red así como sus sistemas operativos.

4. Gestión de proveedores externos
Se exige más compromiso a los proveedores de servicio en el cumplimiento del estándar. Como vimos en el artículo anterior, las organizaciones deben identificar los requisitos cuyo cumplimiento depende de los proveedores, depende de la organización o depende de ambos. Los proveedores que procesen, transmitan o almacenen datos de tarjeta en nombre de la organización deben comprometerse con las organizaciones a cumplir con todos los requisitos PCI DSS que les afecten. Además de incluirse en el clausulado del contrato, la organización deberá auditar a sus proveedores para asegurar que el compromiso es efectivo.

En caso de que el proveedor haya certificado su servicio, éste deberá proporcionar evidencia de que eso es así, bien saliendo publicado en las listas de VISA y MasterCard en caso de pasar la auditoría, o bien entregando el SAQ relleno y firmado por el banco.

Y por último, se pretende aplicar la misma política de control de acceso de los usuarios internos a los proveedores  otorgando cuentas individuales a cualquier proveedor que acceda al entorno PCI DSS. El proveedor debe ser consciente de que está prohibido el uso de cuentas genéricas y compartidas, independientemente de que el acceso sea puntual o habitual. De esta manera se pretende “atar en corto” a los proveedores, y garantizar la imputabilidad a un individuo de todas las acciones que se ejecuten en el sistema.

Con estos requisitos el PCI SSC da una vuelta de tuerca (algunos dirán que dos o tres) al estándar, aumentando la seguridad del entorno no tanto en la parte técnica, sino en la parte administrativa y documental. Lo que se busca es aumentar la seguridad en la gestión de los controles, cerrando agujeros que, en función de la interpretación de las organizaciones y QSAs, podrían causar serios problemas de seguridad.


Autor: Carmen de Alba - CISA, CISM, PCI QSA, PA QSA
Departamento de Consultoría