Éste mes de noviembre ha
visto la luz la tercera versión de PCI DSS. El nuevo documento
incorpora unos cuantos cambios respecto a la versión anterior tanto
en los apartados introductorios como en los propios requisitos y
procedimientos de prueba.
La mayoría de los
cambios tienen como principal objetivo aclarar cuestiones que en la
versión anterior se prestaban a malinterpretaciones o que habían
suscitado numerosas dudas a las organizaciones o incluso a los QSA.
Sin embargo, también nos encontramos con algunos cambios de mayor
calado, como nuevos requisitos, requisitos modificados para hacerlos
más exigentes, o modificados para dar mayor flexibilidad en su
cumplimiento.
Vamos a analizar todos
esos cambios de mayor importancia que incluye la nueva versión:
- Encontramos un nuevo apartado llamado “Implementing PCI DSS into Business-as-Usual” en el que se presentan una serie de buenas prácticas y recomendaciones sobre cómo se debería implementar PCI DSS de manera que se integrara en los procesos de las organizaciones. Cabe destacar que se trata justamente de una serie de buenas prácticas y que por lo tanto no son de obligado cumplimiento ni reemplazan ninguno de los requisitos de las normas PCI DSS. En un futuro 'post' entraré en detalle a analizar este apartado ya que vale la pena revisarlo en profundidad.
- Se ha modificado la tabla en la que se presentan los requisitos, de manera que ahora se incluye una columna en la que se explica la motivación de cada requisito, tal y como en la v2 se hacía en la “navigating guide”. Me parece un cambio muy positivo, ya que esta explicación permitirá en muchos casos entender de forma más completa que se está solicitando exactamente en cada requisito del estándar sin tener que ir a consultar un documento adicional.
- Se han modificado los requisitos 12.1.1 y 12.1.2 de la v2 en los que se solicitaba que todos los requisitos contasen con los procedimientos documentados necesarios. En la v3, se han eliminado incluyéndose en un apartado específico de cada uno de los 11 primeros requisitos. De esta manera no queda duda de qué procedimientos deben documentarse en cada caso.
- Se incluye el requisito 2.4 en el que se indica que la organización debe mantener un inventario de los componentes incluidos en el alcance de PCI DSS para ayudar en el uso de los estándares de configuración a aplicar por la organización para mantener la seguridad de los sistemas.
- Como ya es sabido, el requisito 5 de PCI DSS exige el uso de antivirus en todos los sistemas del alcance excepto en aquellos que se considere que no se ven afectados por malware (Mainframe, AS400, UNIX, etc... ). Como novedad, en la nueva versión se incluye el nuevo requisito 5.1.2 en el que se establece la necesidad de seguir la evolución de los riesgos debidos al malware en sistemas que habitualmente no se ven afectados por malware y en su caso sacarlos de esta categoría.
- Otro nuevo subrequisito incluido dentro del requisito 5 ha sido el 5.3 que solicita que las soluciones antivirus se mantengan activadas y no puedan ser deshabilitadas o alteradas por los usuarios.
- El requisito 6.5.10 se considerará una buena práctica no obligatoria hasta el 1 de junio de 2015. Este requisito establece que en los procedimientos y políticas de desarrollo se deben contemplar medidas que prevengan ataques contra los marcos de autenticación y la gestión de sesiones web, incluyendo los siguientes aspectos:
- Marcar los tokens de sesión (por ejemplo las cookies) con el flag “secure”.
- No exponer las ID de sesión en la URL.
- Incorporar tiempos de expiración y rotación adecuados para las ID de sesión después de un login correcto.
- Se ha modificado el requisito 8.2.3 de manera que este requerimiento ahora establece los mínimos en cuanto a complejidad y tamaño de la contraseña pero permite una mayor flexibilidad en su cumplimiento. Aunque sigue exigiendo que se use una contraseña de 7 o más caracteres y que incluya tanto caracteres numéricos como alfabéticos, se da la posibilidad de utilizar otros tamaños o complejidades siempre y cuando se mantenga igual o mayor robustez en la contraseña a utilizar.
- Se ha incluido un nuevo requisito (8.5.1) que aplicará únicamente a los proveedores de servicios y que obliga a estos a utilizar credenciales diferentes para el acceso remoto a los sistemas de cada uno de sus clientes. Este requisito será considerado una buena práctica no obligatoria hasta el 1 de julio de 2015.
- El nuevo requisito 8.6 obliga a que, en caso de utilizar mecanismos de autenticación diferentes al de usuario/contraseña, estos mecanismos estén ligados de manera unívoca a cuentas de usuario individuales y garantizar que sólo el usuario apropiado pueda hacer uso de dichos mecanismos.
- El requisito 9.3 también es de nueva aparición en esta versión y establece la necesidad de controlar el acceso físico a las áreas sensibles por parte del personal 'onsite'. Así mismo, se deberá contar con procedimientos para autorizar el acceso y revocar dicho acceso de manera inmediata cuando el personal deje de prestar sus servicios en la organización.
- Otros requisitos de nueva aparición en esta versión son los que van del 9.9 al 9.9.3. Estos requisitos exigen que se protejan los dispositivos que capturan los datos de tarjeta directamente mediante la interacción física con las mismas (lectores de tarjeta, etc..). Concretamente, los requisitos solicitan que se mantenga una lista de los dispositivos existentes, que se inspeccionen visualmente de forma periódica para detectar anomalías en los mismos y que se entrene al personal para que pueda detectar si los dispositivos han sido sustituidos o manipulados.
- El requisito 10.5.2 refuerza los requisitos asociados a la generación y revisión de registros de log al requerir que se registren los cambios en los mecanismos de identificación y autenticación, incluyendo la creación de nuevas cuentas o el incremento de privilegios, como por ejemplo el uso del comando “su”.
- El 10.2.6 también se ha visto modificado para solicitar que se incluyan los eventos correspondientes a la parada o pausa de los logs de auditoría, además de la reinicialización o borrado de los logs que ya se exigía en la versión anterior.
- También se ha aumentado la exigencia del requisito 11.1.1 que ahora solicita que se documente el inventario de puntos de acceso wireless autorizados y su correspondiente justificación de negocio.
- Por su parte, el requisito 11.1.2 de nueva creación en la v3 establece la necesidad de que los procedimientos de respuesta ante incidentes detallen el curso de acción a seguir en caso de detectarse redes Wireless no autorizadas en las revisiones trimestrales.
- El requisito 11.3 es uno de los cambios más significativos de esta nueva versión. Tiene carácter de buena práctica hasta el próximo 1 de julio de 2015 fecha a partir de la cual se considerará de obligado cumplimiento. El requisito obliga a que las organizaciones cuenten con una metodología documentada a seguir para la realización de los test de intrusión anuales, tanto internos como externos, con independencia de que sean ejecutados de forma interna por personal de la propia organización o se subcontraten a una organización externa. Esta metodología deberá contemplar, al menos, los siguientes aspectos:
- Deberá estar basada en aproximaciones aceptadas por la industria, como por ejemplo la NIST SP800-115.
- Debe incluir en su alcance todo el perímetro de datos de titulares de tarjeta y los sistemas considerados críticos.
- Debe incluir pruebas desde dentro y desde fuera de la red, es decir, pruebas de intrusión externas e internas.
- Debe incluir pruebas específicas para validar que los controles establecidos para segmentar la red o para reducir el alcance de PCI DSS sean correctos y efectivos.
- Debe incluir pruebas de penetración en la capa de aplicación incluyendo, al menos, las vulnerabilidades listadas en el requisito 6.5 de PCI DSS. Es decir, inyecciones, buffer overflows, almacenamiento inseguro de claves criptográficas, comunicaciones inseguras, gestión incorrecta de los errores, XSS, control de acceso inapropiado, Cross-site request forgery (CSFR), roturas de autenticación o de la gestión de sesiones, o en general cualquier vulnerabilidad categorizada como crítica por parte de la Organización.
- Debe incluir pruebas de penetración en la capa de red que incluyan tanto los componentes y dispositivos de red como sistemas operativos.
- Debe incluir la revisión de las amenazas y vulnerabilidades que hayan afectado a la organización en los últimos 12 meses.
- Debe especificar el periodo de retención de los resultados de las pruebas de penetración y los resultados de las actividades dirigidas a remediar las vulnerabilidades detectadas.
- Adicionalmente, el nuevo procedimiento de test 11.3.b solicita que se corrijan todas las vulnerabilidades explotables encontradas durante las pruebas de intrusión y que se repitan dichas pruebas para verificar dichas correcciones.
- El requisito 11.5 también ha sido modificado para dar mayor flexibilidad en su cumplimiento. Ahora, en lugar de exigir que se instale un FIM, se solicita que se instale algún mecanismo de detección de cambios que permita alertar al personal de modificaciones no autorizadas en ficheros críticos de los sistemas, ficheros de configuración o ficheros de contenido y que se configure el software utilizado para realizar las comparaciones de estos ficheros al menos semanalmente en busca de cambios. Así mismo, el requisito 11.5.1 obliga a disponer de un procedimiento implementado para responder a cualquier alerta generada por la solución de detección de cambios que se utilice.
- Se ha modificado el requisito 12.2 (antiguo 12.1.2) de manera que ahora no sólo se exige la realización de un análisis de riesgo anual, si no también después de cualquier cambio significativo en el entorno (por ejemplo, adquisiciones, fusiones, traslados de sede, etc..).
- El nuevo requisito 12.8.5 solicita que se mantenga documentado el detalle de qué requisitos de PCI DSS son gestionados por cada proveedor de servicios contratado y cuales son gestionados directamente por la entidad.
- Y por último, el nuevo requisito 12.9 será de aplicación únicamente a los proveedores de servicio y se considerará una buena práctica hasta el 1 de julio de 2015. Este requisito obligará a los proveedores de servicios a proveer y firmar con sus clientes de un clausulado específico en el que reconozcan explícitamente su responsabilidad en la gestión de la seguridad de los datos de titulares de tarjeta de sus clientes.
En conclusión, pienso
que todos los cambios incluidos en la nueva versión del estándar
son positivos y que nos encontramos ante un estándar más claro, con
menos zonas grises y que permitiría a las organizaciones que lo
implementen no sólo cumplir con PCI DSS si no además mejorar de
forma significativa la seguridad de los datos de titulares de tarjeta
que almacenen, transmitan o procesen.
Twitter: @omarbenjumea
Linkedin: http://www.linkedin.com/in/omarbenjumea
No hay comentarios:
Publicar un comentario