25/10/2013 Novedades PCI DSS v3.0
El 7 de noviembre sale la versión 3.0 de PCI DSS. El PCI SSC ha empezado a distribuir los borradores de la norma entre los QSAs (Qualified Security Assessors) y he aquí las primeras conclusiones sobre el borrador. Esta nueva versión viene con una profunda revisión de todos los requisitos, derivada de la necesidad de ir evolucionando y perfeccionando la filosofía del estándar con el paso del tiempo, pero, en ningún caso, desdice o invalida requisitos de la versión anterior y la estructura de los 12 requerimientos sigue siendo la misma.
Aunque se han incluido varios requisitos (alrededor de 30 nuevos), se puede decir que la nueva versión requiere un esfuerzo extra por parte de las organizaciones en la parte documental. El PCI SSC da por hecho que la red se segmenta, que se recogen logs de todos los componentes, que los sistemas son bastionados, etc., pero la parte documental y procedimental no está correctamente desarrollado o implantado, y en este aspecto se centran la mayoría de los cambios y aclaraciones introducidos.
Analizando el borrador se puede decir que, en primer lugar, se han modificado un gran número de requisitos para eliminar ambigüedades en aquellos que permitían interpretaciones diferentes, tanto en QSAs como en el personal de las organizaciones. Y en segundo lugar, se han desarrollado nuevos requisitos que pretenden cubrir ciertas carencias que tiene la versión 2.0. De entre estos nuevos requisitos añadidos cabe destacar aquellos que, por el impacto que tiene su aplicación en el entorno PCI DSS, hasta junio de 2015 serán considerados como buenas prácticas y a partir de esta fecha serán requisitos de obligado cumplimiento.
En este primer artículo se analizan por requerimientos los nuevos requisitos más significativos, dejando para posteriores artículos los requisitos que son buenas prácticas hasta junio de 2015 y los requisitos modificados.
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Respecto a los mapas de red detallados, se exige que en éstos aparezcan los flujos de datos de tarjeta a través de las redes y sistemas.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Para mantener un control estricto de todos los componentes del entorno, se requiere mantener actualizado un inventario de activos al nivel de hardware y de software. Este requisito está relacionado con el mapa de red. Con un inventario completo de los componentes y tecnologías del entorno PCI DSS, es más sencillo verificar que en el mapa de red se han tenido en cuenta todos los componentes del entorno sin inconsistencias.
Requirement 3: Protect stored cardholder data
En relación a la visualización de los datos de tarjeta en claro, se incluye un nuevo requisito que exige que todos los roles de las personas que accedan a los datos de tarjeta en claro deben estar identificados. Este nuevo requisito enlaza con los requisitos de control de acceso del requerimiento 7, obligando a las organizaciones a tener una relación entre aplicaciones, ficheros, logs, etc. que contienen datos de tarjeta, y los roles autorizados para cada uno de ellos.
Por lo tanto, deberá existir una “Matriz de Acceso al PAN Completo”, donde se justifique, para cada uno de los roles autorizados, la necesidad de acceder al dato en claro, y cualquier otro rol que no aparezca en esta matriz deberá ver los datos de tarjeta enmascarados.
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Para aquellos equipos que no sean susceptibles de ser afectados por malware (mainframe, sistemas UNIX, etc.), se deberá realizar un análisis periódico, en el que se analicen si los riesgos actuales podrían afectar de algún modo a dichos equipos. Esto implica que se deben revisar las publicaciones de los fabricantes de dichos equipos, las publicaciones de los fabricantes de antivirus, las publicaciones de seguridad de distintas organizaciones expertas en temas de seguridad, que permitan identificar si estos componentes corren el riesgo de verse afectados por cualquier tipo de malware.
Además, las organizaciones deberán tener en su repositorio documental las características de los antivirus activos en el entorno PCI DSS, en el que se pueda verificar que dichos antivirus protegen los componentes del entorno y detectan y eliminan todo tipo de software malicioso conocido.
Requirement 7: Restrict access to cardholder data by business need to know
Para cada uno de los componentes del entorno, se deben identificar los roles que necesitan acceso, así como los privilegios que tienen. Lo más recomendable es establecer una matriz de control de acceso. Este requisito viene a completar la gestión de accesos de los usuarios del entorno PCI DSS.
A pesar del trabajo adicional que implica documentar para cada componente del entorno, los roles y permisos asociados, este control permite tener una gestión eficaz y ordenada de los roles y usuarios.
Requirement 8: Identify and authenticate access to system components
En esta nueva revisión se ha incluido la gestión de credenciales para el control de acceso físico. Por lo tanto, se deberá establecer un procedimiento de altas y bajas de los usuarios, en los que se tenga en cuenta que si a un empleado se le entrega una tarjeta inteligente, un token u otro dispositivo de autenticación, éste deberá ser devuelto en el momento en que el usuario cause baja en la empresa o cambie el puesto de trabajo.
También se especifica que, cualquier dispositivo físico de autenticación entregado a cualquier empleado, es de uso personal e intransferible, y que deberá verificarse que dichos dispositivos no son compartidos entre varios usuarios.
Requirement 9: Restrict physical access to cardholder data
En la versión 2.0 se obligaba a controlar y gestionar los accesos físicos a CPDs de las visitas. A partir de ahora, también deberá gestionarse y controlarse los accesos físicos del personal interno y externo de la organización. Como todo lo relativo al control de acceso, los permisos de acceso deben basarse en función de su trabajo, y éstos deben ser revocados de manera inmediata cuando un empleado cause baja en la empresa o cambie de puesto de trabajo (y ya no sea necesario tener acceso a zonas específicas).
Respecto a la gestión de destrucción de soportes, la nueva versión puntualiza que, aquellos contenedores que almacenen información con datos sensibles, deberán securizarse asegurando que no podrán ser accesibles por personal no autorizado.
Requirement 10: Track and monitor all access to network resources and cardholder data
Tanto para las alertas generadas por la plataforma de centralización y correlación de logs como para las alertas generadas por la aplicación de monitorización de archivos críticos, se debe establecer un proceso de revisión y gestión de alertas. Es decir, debe haber unos procedimientos documentados que permitan gestionar el ciclo de vida de las alertas, desde el momento en que un operador las detecta hasta que éstas se cierran.
Requirement 11: Regularly test security systems and processes
A los tests de intrusión se le añade una nueva funcionalidad: verificar de forma global, que la segmentación es efectiva y los controles implantados están operativos y funcionan de acuerdo a lo establecido, aislando los componentes dentro del entorno de otras redes y componentes no confiables.
Requirement 12: Maintain a policy that addresses information security for all personnel
Respecto a la gestión de proveedores, para cada servicio prestado por los proveedores, se deberán mapear los requisitos que son responsabilidad del proveedor de servicios, los requisitos que son responsabilidad de la organización, y los requisitos cuya responsabilidad sea compartida por el proveedor de servicios y la organización.
Por último, cabe destacar que el requisito 12.2 (“Develop daily operational security procedures that are consistent with requirements in this specification (for example, user account maintenance procedures, and log review procedures)”) de la norma ha sido eliminado, y en su lugar, al final de cada requerimiento, se ha incluido un requisito que exige documentar y distribuir a todos los empleados internos y externos las políticas, los procedimientos, las instrucciones de trabajo, etc. para que puedan operar de acuerdo a éstos.
Fuente: Isecauditor
Aunque se han incluido varios requisitos (alrededor de 30 nuevos), se puede decir que la nueva versión requiere un esfuerzo extra por parte de las organizaciones en la parte documental. El PCI SSC da por hecho que la red se segmenta, que se recogen logs de todos los componentes, que los sistemas son bastionados, etc., pero la parte documental y procedimental no está correctamente desarrollado o implantado, y en este aspecto se centran la mayoría de los cambios y aclaraciones introducidos.
Analizando el borrador se puede decir que, en primer lugar, se han modificado un gran número de requisitos para eliminar ambigüedades en aquellos que permitían interpretaciones diferentes, tanto en QSAs como en el personal de las organizaciones. Y en segundo lugar, se han desarrollado nuevos requisitos que pretenden cubrir ciertas carencias que tiene la versión 2.0. De entre estos nuevos requisitos añadidos cabe destacar aquellos que, por el impacto que tiene su aplicación en el entorno PCI DSS, hasta junio de 2015 serán considerados como buenas prácticas y a partir de esta fecha serán requisitos de obligado cumplimiento.
En este primer artículo se analizan por requerimientos los nuevos requisitos más significativos, dejando para posteriores artículos los requisitos que son buenas prácticas hasta junio de 2015 y los requisitos modificados.
Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Respecto a los mapas de red detallados, se exige que en éstos aparezcan los flujos de datos de tarjeta a través de las redes y sistemas.
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
Para mantener un control estricto de todos los componentes del entorno, se requiere mantener actualizado un inventario de activos al nivel de hardware y de software. Este requisito está relacionado con el mapa de red. Con un inventario completo de los componentes y tecnologías del entorno PCI DSS, es más sencillo verificar que en el mapa de red se han tenido en cuenta todos los componentes del entorno sin inconsistencias.
Requirement 3: Protect stored cardholder data
En relación a la visualización de los datos de tarjeta en claro, se incluye un nuevo requisito que exige que todos los roles de las personas que accedan a los datos de tarjeta en claro deben estar identificados. Este nuevo requisito enlaza con los requisitos de control de acceso del requerimiento 7, obligando a las organizaciones a tener una relación entre aplicaciones, ficheros, logs, etc. que contienen datos de tarjeta, y los roles autorizados para cada uno de ellos.
Por lo tanto, deberá existir una “Matriz de Acceso al PAN Completo”, donde se justifique, para cada uno de los roles autorizados, la necesidad de acceder al dato en claro, y cualquier otro rol que no aparezca en esta matriz deberá ver los datos de tarjeta enmascarados.
Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs
Para aquellos equipos que no sean susceptibles de ser afectados por malware (mainframe, sistemas UNIX, etc.), se deberá realizar un análisis periódico, en el que se analicen si los riesgos actuales podrían afectar de algún modo a dichos equipos. Esto implica que se deben revisar las publicaciones de los fabricantes de dichos equipos, las publicaciones de los fabricantes de antivirus, las publicaciones de seguridad de distintas organizaciones expertas en temas de seguridad, que permitan identificar si estos componentes corren el riesgo de verse afectados por cualquier tipo de malware.
Además, las organizaciones deberán tener en su repositorio documental las características de los antivirus activos en el entorno PCI DSS, en el que se pueda verificar que dichos antivirus protegen los componentes del entorno y detectan y eliminan todo tipo de software malicioso conocido.
Requirement 7: Restrict access to cardholder data by business need to know
Para cada uno de los componentes del entorno, se deben identificar los roles que necesitan acceso, así como los privilegios que tienen. Lo más recomendable es establecer una matriz de control de acceso. Este requisito viene a completar la gestión de accesos de los usuarios del entorno PCI DSS.
A pesar del trabajo adicional que implica documentar para cada componente del entorno, los roles y permisos asociados, este control permite tener una gestión eficaz y ordenada de los roles y usuarios.
Requirement 8: Identify and authenticate access to system components
En esta nueva revisión se ha incluido la gestión de credenciales para el control de acceso físico. Por lo tanto, se deberá establecer un procedimiento de altas y bajas de los usuarios, en los que se tenga en cuenta que si a un empleado se le entrega una tarjeta inteligente, un token u otro dispositivo de autenticación, éste deberá ser devuelto en el momento en que el usuario cause baja en la empresa o cambie el puesto de trabajo.
También se especifica que, cualquier dispositivo físico de autenticación entregado a cualquier empleado, es de uso personal e intransferible, y que deberá verificarse que dichos dispositivos no son compartidos entre varios usuarios.
Requirement 9: Restrict physical access to cardholder data
En la versión 2.0 se obligaba a controlar y gestionar los accesos físicos a CPDs de las visitas. A partir de ahora, también deberá gestionarse y controlarse los accesos físicos del personal interno y externo de la organización. Como todo lo relativo al control de acceso, los permisos de acceso deben basarse en función de su trabajo, y éstos deben ser revocados de manera inmediata cuando un empleado cause baja en la empresa o cambie de puesto de trabajo (y ya no sea necesario tener acceso a zonas específicas).
Respecto a la gestión de destrucción de soportes, la nueva versión puntualiza que, aquellos contenedores que almacenen información con datos sensibles, deberán securizarse asegurando que no podrán ser accesibles por personal no autorizado.
Requirement 10: Track and monitor all access to network resources and cardholder data
Tanto para las alertas generadas por la plataforma de centralización y correlación de logs como para las alertas generadas por la aplicación de monitorización de archivos críticos, se debe establecer un proceso de revisión y gestión de alertas. Es decir, debe haber unos procedimientos documentados que permitan gestionar el ciclo de vida de las alertas, desde el momento en que un operador las detecta hasta que éstas se cierran.
Requirement 11: Regularly test security systems and processes
A los tests de intrusión se le añade una nueva funcionalidad: verificar de forma global, que la segmentación es efectiva y los controles implantados están operativos y funcionan de acuerdo a lo establecido, aislando los componentes dentro del entorno de otras redes y componentes no confiables.
Requirement 12: Maintain a policy that addresses information security for all personnel
Respecto a la gestión de proveedores, para cada servicio prestado por los proveedores, se deberán mapear los requisitos que son responsabilidad del proveedor de servicios, los requisitos que son responsabilidad de la organización, y los requisitos cuya responsabilidad sea compartida por el proveedor de servicios y la organización.
Por último, cabe destacar que el requisito 12.2 (“Develop daily operational security procedures that are consistent with requirements in this specification (for example, user account maintenance procedures, and log review procedures)”) de la norma ha sido eliminado, y en su lugar, al final de cada requerimiento, se ha incluido un requisito que exige documentar y distribuir a todos los empleados internos y externos las políticas, los procedimientos, las instrucciones de trabajo, etc. para que puedan operar de acuerdo a éstos.
Fuente: Isecauditor
Comentarios
Publicar un comentario
siempre es bueno, leer tus comentarios