08 noviembre 2010

PCI-DSS 2.0: Mi análisis de los cambios

Como much@s de vosotr@s sabréis, recientemente se ha publicado la versión 2.0 del estándar PCI-DSS, por lo que he pensado que podría ser interesante compartir mi análisis de los cambios (el PCI Council ha publicado un documento titulado "Summary of Changes from PCI DSS Version 1.2.1 to 2.0" para ayudarnos en esta tarea).

Lo primero que habría que decir es que, del total de 137 cambios inventariados en dicho documento, la gran mayoría - casi un 88% - son clarificaciones, mientras que solo hay 15 casos de orientación adicional y exclusivamente 2 requerimientos que han evolucionado. Es decir, que podríamos decir que la versión 2.0 del estándar es, principalmente, aclaratoria.

Una vez dicho esto, los cambios que más han llamado la atención (por orden de impacto, más o menos) han sido los siguientes:
  • Se ha incluido una nota adicional en 3.2 sobre la posibilidad de almacenar los datos sensibles de autenticación en el caso de emisores de tarjetas (ya lo habíamos comentado antes por aquí), siempre que exista una justificación de negocio y se almacenen de manera segura.
  • Los requerimientos de calificar las vulnerabilidades, además de identificarlas y de solventar las de riesgo "alto" (best practice hasta el 30 de junio de 2012) [estos son los dos requerimientos que han evolucionado].
  • Requerimiento 2.1.1 - Se ha eliminado WPA puesto que no se puede considerar como cifrado fuerte.
  • Se ha relajado la necesidad de cambio anual de claves de cifrado que establecía el requerimiento 3.6.4, por lo que se haya definido en su caducidad. También en el 3.6.6, se ha concretado que el conocimiento compartido solo aplica para operaciones de gestión de claves en texto-en-claro.
  • Se ha incluido un requerimiento nuevo (2.2.b) para asegurar que las guías de configuración de los sistemas se actualizan con las vulnerabilidades identificadas en el 6.
  • Respecto al requerimiento 2.2.1, se clarificado que, al hablar de "una función primaria por servidor" y en el caso de virtualización, se puede instalar solo una función principal por elemento.
  • El requerimiento 3.1.1.e  incluye test adicional para el QSA: Verificar que los datos almacenados no exceden de los períodos de retención fijados en la política de la entidad.
  • Requerimiento 1.3.8 - Se ha eliminado la referencia a NAT, centrándose en el objetivo: Prevenir que se revelen las direcciones IP privadas.
  • La aclaración del requerimiento 6.5, en cuanto a que la programación segura aplica a todas las aplicaciones desarrolladas a medida y no solo a las aplicaciones web.
  • Requerimiento 8.5.16 - Se ha aclarado que los accesos directos a bases de datos no autorizados son los de los usuarios finales.
  • Requerimiento 9 - Se sustituye el término "empleado" por "personal insitu" que incluye también terceros y otros usuarios que trabajan en las dependencias de la entidad.
  • Se amplían las opciones para detectar puntos de acceso wireless no autorizados en el requerimiento 11.1.
  • En el requerimiento 11.4 se ha simplificado y aclarado lo que se espera de los IDS/IPS.

Perdonar, si ha quedado una entrada un poco larga, pero no me ha quedado más remedio.

¿Qué opináis? ¿Me he dejado algún cambio importante? 

... ¿Todavía no me sigues en twitter.com/antonio_ramosga?

4 comentarios:

Anónimo dijo...

Con respecto al requerimiento de calificar las vulnerabilidades, además de identificarlas y de solventar las de riesgo "alto" (best practice hasta el 30 de junio de 2012), ¿el SSC va a fijar los criterios para calificar las vulnerabilidades, o será a interpretación de cada QSA? ¿qué sucede con aquellas no identificadas como riesgo "alto"? ¿hasta el 30/06/12, todas las vulnerabilidades se entienden de riesgo "alto"?

Antonio Ramos dijo...

Hola, Anónimo.

Estas modificaciones aparecen en los requerimientos 6.2 y 6.5.6.

En el 6.2, se habla de establecer un proceso para identificar y calificar la nuevas vulnerabilidades de seguridad que se descubran. Respecto a tu pregunta, el criterio debe ser una best practice de la industria (p.e. CVSS) y lo que nos dice es que, como mínimo, las más críticas, deberían ser clasificadas como de riesgo "alto".

El 6.5.6 está encuadrado en el requerimiento que nos pide desarrollar aplicaciones basadas conforme a guías de configuración segura y prevenir las vulnerabilidades típicas en los procesos de desarrollo para incluir, entre otras, las vulnerabilidades "altas" identificadas en el punto anterior y que, en cualquier caso, serán las que toquen en cada momento, en línea con las típicas listas de OWASP, SANS, etc.). De esta forma, las aplicaciones que se ponen en producción nunca deberían tener vulnerabilidades de nivel alto, aunque sí de nivel medio o bajo...

Perdona por la longitud del comentario.

Álvaro Del Hoyo dijo...

Buenas, Antonio

Al hilo del PCI DSS y en relación con la LOPD...mira en los comentarios

http://www.ayudaleyprotecciondatos.es/2010/12/02/firma-tableta-electronica/

http://www.ayudaleyprotecciondatos.es/2010/12/13/identificacion-mediante-pin/

Ya sé que PCI DSS no llega hasta este punto, pero creo que no se ha de olvidar que la gestión de seguridad de los pagos no se recoge completamente con PCI DSS

Un saludo

Antonio Ramos dijo...

Efectivamente, Álvaro.

PCI DSS solo cubre una parte de la cadena de procesamiento, en concreto, los datos de autenticación del titular de tarjeta pero existen otros estándares que cubren otros aspectos: PA-DSS, PCI PED, etc.