Siguiendo su ciclo de tres años, este año el PCI SSC se ha adelantado y ha publicado nueva versión de sus estándares más importantes como lo son el PCI DSS y el PA DSS, en ambos (la versión anterior era la 3.1) han publicado entre los meses de Abril y Mayo la nuevas versiones PCI DSS 3.2 y PA DSS 3.2. Pero, ¿qué nos trae de nuevo esta versión de la norma? Para aclarar esto, primero abarcaremos los cambios que nos trae esta nueva versión para luego revisar el detalle y poder identificar los retos que implica llegar al cumplimiento de las aplicaciones.
Para detallar cuales son los nuevos cambios que incorpora la norma y los retos que eso nos implica, es necesario entender los tipos de cambios que se presentaron en la nueva versión:
Por otro lado, la norma (PA DSS) tiene otros principales cambios que son importantes de remarcar:
En consecuencia, la norma nos plantea nuevos retos que deben ser adecuados para las solicitudes de certificación a partir del 31 de Agosto del 2016, fecha en la que el estándar PA DSS 3.1 deja de ser válido y entra en vigencia únicamente la versión 3.2. Por lo tanto, es necesario entender estos nuevos ajustes que fueron presentados, desglosando los cambios para entender mejor su implicación y qué tareas será necesario llevar a cabo para poder lograr su cumplimiento.
En la nueva versión se retiran los ejemplos de protocolos de seguridad o seguros. Los protocolos de seguridad son protocolos de red designados para asegurar las transmisiones de datos, por ejemplo, y no limitado a, TLS, IPSEC, SSH, HTTPS, etc. Se retiran los ejemplos debido a que no se tiene certeza lo que a un futuro sea un protocolo fuerte de cifrado, por lo tanto los fabricantes de software deben estar actualizados en cuanto a las vulnerabilidades de los protocolos utilizados o soportados por su aplicación y en caso de contar con alguno vulnerable, se debe realizar la migración a alguno si considerado como seguro. Para mantenerse el día en este tipo de noticias es recomendable estar afiliados a boletines de noticias de seguridad como lo son el del US CERT ( https://www.us-cert.gov/ncas/bulletins), AU CERT ( https://www.auscert.org.au/render.html?cid=1), entre otros. Para aplicaciones que están en su primera solicitud de certificación es indispensable que en la valoración de riesgos de la aplicación (labor a realizar en el momento del diseño de la aplicación) se identifiquen estos tipos de requerimientos o dependencias para garantizar que la aplicación no use o soporte protocolos inseguros.
Por otro lado, la norma aclara en el requerimiento 2.2 que debe obligarse a tener autorización para visualizaciones del PAN (Primary Account Number, es decir el número de la tarjeta) completo, y el que no cuente con dicha autorización, debe verlo enmascarado. Se aclara que el PA QSA debe validar en las pantallas donde se muestra el PAN y validar como se configura la aplicación para poder garantizar que sólo las personas con la necesidad legítima de negocio pueden verlo completo. Esto implica que se debe definir un proceso para dicho fin y se debe poder configurar a nivel de aplicación qué usuarios pueden ver el PAN completo y cuales lo deben ver enmascarado, puede ser definiendo diferentes perfiles y requiriendo autorización para poder asociar el perfil con vista completa a los usuarios definidos. Así mismo, dicho procedimiento de cómo realizar esta labor debe estar documentado en la Guía de Implementación. Complementando eso, se define los requerimientos de enmascarado en donde se puede mostrar máximo los 6 primeros de la tarjeta (BIN – Bank Identification Number) y los cuatro últimos, especificando que si sólo se requieren los últimos 4 se pueden mostrar sin necesidad del BIN.
Así mismo, se complementó el procedimiento de test 2.3.a para incluir que sí está habilitada la depuración de la aplicación (por ejemplo para solución de problemas) y el PAN es incluido en los logs de depuración, estos log deben ser protegidos de acuerdo a lo mencionado por PCI DSS. Esto implicaría que estos logs deben almacenarse cifrados, deben ser protegidos para que no sean alterados y debe restringirse su consulta sólo al personal con la necesidad de conocer, deshabilitarse una vez se hayan solucionado todos los problemas y borrado seguro sobre todos los logs generados. Por tanto, se debe incluir en la guía de implementación una descripción del proceso de los pasos mencionados anteriormente y así mismo modificar las aplicaciones para que se cumpla con lo requerido para estos logs de depuración.
Otro cambio exigido por la nueva norma en el requerimiento 5.1.7, es que la capacitación a los desarrolladores referente a implementar seguridad en el ciclo de vida del desarrollo de software, codificación segura, revisión de código, manejo de información sensible en memoria, pruebas de seguridad y técnicas de valoración de riesgos a las aplicaciones se realicen anualmente y se encuentre actualizada a los nuevos retos, tecnologías, vulnerabilidades, amenazas, etc. que hay en el mercado. Estas capacitaciones pueden ser impartidas por personal interno capacitado o terceros, en sitio o virtuales.
Otra aclaración que la norma implementó es sobre la autenticación utilizando diversos factores, donde se habla de multi-factor. En la autenticación existen diferentes tipos de factores los cuales son:
Un nuevo requerimiento planteado en la norma es el 7.2.3. Este numeral requiere instrucciones sobre cómo instalar de forma segura los parches y/o actualizaciones. Para lo cual los fabricantes de software deben documentar las instrucciones en cómo se va a notificar a los clientes sobre parches y actualizaciones, cómo van a ser distribuidos de forma segura e instrucciones en cómo debe instalarse de manera segura para que no se pierda la integridad del código. Esto implica que se debe incluir en la Guía de Implementación pautas para este requerimiento y el reto principal es definir mecanismos y procedimientos para poder entregar las modificaciones en el código a los clientes sin que se impacte la seguridad del mismo.
Finalmente, se hacen aclaraciones en la norma como el cambio de nombre del requerimiento 12 para que refleje más la intención del requerimiento, el cual es el proteger las conexiones administrativas dado que se maneja información sensible (como credenciales de los administradores). Y, otras aclaraciones son sobre el Apéndice A (resumen del contenido de la guía de implementación) para reflejar los cambios en todos los requerimientos que cambiaron y que impactan la guía.
Como conclusión se puede observar que los cambios sobre la norma están orientados a proteger las comunicaciones entrantes y salientes de las aplicaciones, proteger la información sensible y estar al día con las amenazas emergentes y cambios en el mercado. Sin embargo, los cambios no son de gran impacto para aplicaciones ya certificadas o en proceso de certificación ya que la mayoría de los cambios son aclaraciones y los impactos nuevos, en su mayoría recaen sobre la guía de implementación. Por tanto, el reto y el mayor impacto afecta a la actualización de la guía de implementación y muy pocos cambios sobre el diseño y/o codificación de las aplicaciones.
Referencias
Autor: David A. González - PCI-QSA, PA-QSA, PCIP
Departamento de Consultoría.
Para detallar cuales son los nuevos cambios que incorpora la norma y los retos que eso nos implica, es necesario entender los tipos de cambios que se presentaron en la nueva versión:
- Aclaraciones: Explicaciones de la intención de los requerimientos.
- Guías Adicionales: Explicaciones, definiciones o instrucciones que aumentan el entendimiento de la norma.
- Requerimientos que evolucionan: Cambios a la norma que aseguran que el estar está actualizado a las nuevas amenazas y cambios en el mercado.
Por otro lado, la norma (PA DSS) tiene otros principales cambios que son importantes de remarcar:
|
Req
|
Cambio
|
Tipo
|
|
-
|
Se retiran ejemplos de protocolos fuertes
|
Aclaración
|
|
2.2
|
Remarca la necesidad de tener una justificación de negocio (business need) para mostrar PAN no enmascarado y ejemplos de enmascaramientos de PAN
|
Nuevo Requerimiento
|
|
2.3.a (procedimiento de test)
|
Cuando se requieran logs de depuración de la aplicación y estos contengan PAN, deben ser protegidos de acuerdo a lo requerido por PCI DSS, desactivados tan pronto como se finalizan las tareas de depuración y eliminados de forma segura una vez no se necesitan
|
Nuevo Requerimiento
|
|
5.1.7
|
La capacitación a los desarrolladores debe estar actualizada y realizarse anualmente
|
Aclaración
|
|
7.2.3
|
Instrucciones en la Guía de Implementación en cómo instalar los parches y actualizaciones en forma segura
|
Nuevo Requerimiento
|
|
8.3, 10.1
|
Aclaración del término autenticación por multi-factor.
|
Aclaración
|
|
Requerimiento 12
|
Requerimiento 12 cuenta con un nuevo nombre: Asegurar todos los accesos administrativos que no son por consola
|
Aclaración
|
|
12.2
|
Todos los accesos que no son por consola deben utilizar autenticación multi-factor
|
Nuevo Requerimiento
|
|
Apéndice A
|
Actualizaciones al apéndice A (Resumen de contenido de la Guía de Implementación) teniendo en cuenta todos los cambios en la norma
|
Aclaración
|
En consecuencia, la norma nos plantea nuevos retos que deben ser adecuados para las solicitudes de certificación a partir del 31 de Agosto del 2016, fecha en la que el estándar PA DSS 3.1 deja de ser válido y entra en vigencia únicamente la versión 3.2. Por lo tanto, es necesario entender estos nuevos ajustes que fueron presentados, desglosando los cambios para entender mejor su implicación y qué tareas será necesario llevar a cabo para poder lograr su cumplimiento.
En la nueva versión se retiran los ejemplos de protocolos de seguridad o seguros. Los protocolos de seguridad son protocolos de red designados para asegurar las transmisiones de datos, por ejemplo, y no limitado a, TLS, IPSEC, SSH, HTTPS, etc. Se retiran los ejemplos debido a que no se tiene certeza lo que a un futuro sea un protocolo fuerte de cifrado, por lo tanto los fabricantes de software deben estar actualizados en cuanto a las vulnerabilidades de los protocolos utilizados o soportados por su aplicación y en caso de contar con alguno vulnerable, se debe realizar la migración a alguno si considerado como seguro. Para mantenerse el día en este tipo de noticias es recomendable estar afiliados a boletines de noticias de seguridad como lo son el del US CERT ( https://www.us-cert.gov/ncas/bulletins), AU CERT ( https://www.auscert.org.au/render.html?cid=1), entre otros. Para aplicaciones que están en su primera solicitud de certificación es indispensable que en la valoración de riesgos de la aplicación (labor a realizar en el momento del diseño de la aplicación) se identifiquen estos tipos de requerimientos o dependencias para garantizar que la aplicación no use o soporte protocolos inseguros.
Por otro lado, la norma aclara en el requerimiento 2.2 que debe obligarse a tener autorización para visualizaciones del PAN (Primary Account Number, es decir el número de la tarjeta) completo, y el que no cuente con dicha autorización, debe verlo enmascarado. Se aclara que el PA QSA debe validar en las pantallas donde se muestra el PAN y validar como se configura la aplicación para poder garantizar que sólo las personas con la necesidad legítima de negocio pueden verlo completo. Esto implica que se debe definir un proceso para dicho fin y se debe poder configurar a nivel de aplicación qué usuarios pueden ver el PAN completo y cuales lo deben ver enmascarado, puede ser definiendo diferentes perfiles y requiriendo autorización para poder asociar el perfil con vista completa a los usuarios definidos. Así mismo, dicho procedimiento de cómo realizar esta labor debe estar documentado en la Guía de Implementación. Complementando eso, se define los requerimientos de enmascarado en donde se puede mostrar máximo los 6 primeros de la tarjeta (BIN – Bank Identification Number) y los cuatro últimos, especificando que si sólo se requieren los últimos 4 se pueden mostrar sin necesidad del BIN.
Así mismo, se complementó el procedimiento de test 2.3.a para incluir que sí está habilitada la depuración de la aplicación (por ejemplo para solución de problemas) y el PAN es incluido en los logs de depuración, estos log deben ser protegidos de acuerdo a lo mencionado por PCI DSS. Esto implicaría que estos logs deben almacenarse cifrados, deben ser protegidos para que no sean alterados y debe restringirse su consulta sólo al personal con la necesidad de conocer, deshabilitarse una vez se hayan solucionado todos los problemas y borrado seguro sobre todos los logs generados. Por tanto, se debe incluir en la guía de implementación una descripción del proceso de los pasos mencionados anteriormente y así mismo modificar las aplicaciones para que se cumpla con lo requerido para estos logs de depuración.
Otro cambio exigido por la nueva norma en el requerimiento 5.1.7, es que la capacitación a los desarrolladores referente a implementar seguridad en el ciclo de vida del desarrollo de software, codificación segura, revisión de código, manejo de información sensible en memoria, pruebas de seguridad y técnicas de valoración de riesgos a las aplicaciones se realicen anualmente y se encuentre actualizada a los nuevos retos, tecnologías, vulnerabilidades, amenazas, etc. que hay en el mercado. Estas capacitaciones pueden ser impartidas por personal interno capacitado o terceros, en sitio o virtuales.
Otra aclaración que la norma implementó es sobre la autenticación utilizando diversos factores, donde se habla de multi-factor. En la autenticación existen diferentes tipos de factores los cuales son:
- Algo que se sabe (p.e. usuario/contraseña, passphrase )
- Algo que se es (p.e. huella digital)
- Algo que se tiene (p.e. Token, Certificado digital, tarjeta de coordenadas)
Un nuevo requerimiento planteado en la norma es el 7.2.3. Este numeral requiere instrucciones sobre cómo instalar de forma segura los parches y/o actualizaciones. Para lo cual los fabricantes de software deben documentar las instrucciones en cómo se va a notificar a los clientes sobre parches y actualizaciones, cómo van a ser distribuidos de forma segura e instrucciones en cómo debe instalarse de manera segura para que no se pierda la integridad del código. Esto implica que se debe incluir en la Guía de Implementación pautas para este requerimiento y el reto principal es definir mecanismos y procedimientos para poder entregar las modificaciones en el código a los clientes sin que se impacte la seguridad del mismo.
Finalmente, se hacen aclaraciones en la norma como el cambio de nombre del requerimiento 12 para que refleje más la intención del requerimiento, el cual es el proteger las conexiones administrativas dado que se maneja información sensible (como credenciales de los administradores). Y, otras aclaraciones son sobre el Apéndice A (resumen del contenido de la guía de implementación) para reflejar los cambios en todos los requerimientos que cambiaron y que impactan la guía.
Como conclusión se puede observar que los cambios sobre la norma están orientados a proteger las comunicaciones entrantes y salientes de las aplicaciones, proteger la información sensible y estar al día con las amenazas emergentes y cambios en el mercado. Sin embargo, los cambios no son de gran impacto para aplicaciones ya certificadas o en proceso de certificación ya que la mayoría de los cambios son aclaraciones y los impactos nuevos, en su mayoría recaen sobre la guía de implementación. Por tanto, el reto y el mayor impacto afecta a la actualización de la guía de implementación y muy pocos cambios sobre el diseño y/o codificación de las aplicaciones.
Referencias
- Summary of Changes from PA-DSS Version 3.1 to 3.2 : https://www.pcisecuritystandards.org/documents/PA-DSS_v3-2_Summary_of_Changes.pdf?agreement=true&time=1473327728880
- Payment Card Industry (PCI) Payment Application Data Security Standard, v3.2 : https://www.pcisecuritystandards.org/documents/PA-DSS_v3-2.pdf?agreement=true&time=1473327728857
- Fechas clave para la retirada de PA-DSS v3.1: http://blog.isecauditors.com/2016/06/fechas-clave-para-la-retirada-de-pa-dss.html
- Autenticación multi-factor (MFA): la nueva apuesta de seguridad de PCI DSS v3.2: http://blog.isecauditors.com/2016/07/autenticacion-multi-factor-la-nueva-apuesta-seguridad-pcidssv3.2.html
- Glossary of Terms, Abbreviations, and Acronyms PCI DSS PA DSS v 3.2: https://www.pcisecuritystandards.org/documents/PCI_DSS_Glossary_v3-2.pdf?agreement=true&time=1473354553922
Autor: David A. González - PCI-QSA, PA-QSA, PCIP
Departamento de Consultoría.