Blog de Internet Security Auditors

Blog de Internet Security Auditors: Los nuevos retos que nos trae PA DSS en la versión 3.2.

Escrito por Internet Security Auditors | Sep 12, 2016 4:00:00 AM
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:
  • 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.
Dicho esto,  el PCI SSC hizo un cambio importante con respecto a las versiones anteriores en cuanto a la exigencia de migración de los protocolos SSL e implementaciones tempranas de TLS, a protocolos seguros. En esta nueva entrega, se otorga un plazo a las entidades de migrar hasta junio del 2018, sin embargo las aplicaciones que deseen tener el cumplimiento en PA DSS no deben usar o soportar estos protocolos inseguros dado que no son considerados criptografía fuerte tal como lo menciona la norma “ …SSL e implementaciones tempranas de TLS no se consideran criptografía fuerte. Las Aplicaciones de pago no deben usar, o apoyar el uso de SSL e implementaciones tempranas de TLS. Las aplicaciones que utilizan o soportan TLS no deben permitir un retroceso a SSL…” .Inclusive PCI DSS v3.2. tiene un ANEXO A2 que abarca la exigencia de la migración. Esta migración es necesaria dado las diferentes vulnerabilidades encontradas en estos protocolos.

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)
En versiones anteriores, la norma daba como válida la autenticación de doble factor, en donde se debía utilizar dos factores para autenticaciones remotas, sin embargo en esta nueva versión, aclararon que la terminología correcta es “multi-factor” en donde es posible utilizar dos o más factores en el momento de autenticar conexiones remotas. Tema que también nos lleva a hablar sobre el nuevo requerimiento 12.2, el cual exige que todos los accesos administrativos que no sean por consola, deben ser mediante autenticación multi-factor. Por lo tanto las aplicaciones deben proveer este tipo de autenticaciones, como por ejemplo validar tokens, certificados digitales, tarjetas de coordenadas, etc. adicionalmente a la validación de usuario y contraseña o poder soportar de otras herramientas para estos tipos de autenticación.

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.
Ver post completo