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
