Presentación de Miguel Ángel Domínguez de Internet Security Auditors en la que se explicaron las novedades de las versiones 2.0 de las normas PCI DSS y PA DSS

1. 1
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
NOVEDADES PCI DSS V2.0 Y PA-DSS V2.0
MIGUEL ÁNGEL DOMÍNGUEZ
DIRECTOR DEPTO. CONSULTORÍA / QSA
MANAGER
INTERNET SECURITY AUDITORS

2. 2
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
2
ÍNDICE
 Novedades PCI DSS Versión 2.0
 Novedades PA DSS Versión 2.0

3. 3
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
3
 Aclaraciones
 Cambios principalmente del texto
con el objetivo de explicar mejor el
objetivo deseado con el requisito.
 Guía Adicional
 Introduce ejemplos o definiciones
que permiten aumentar el
entendimiento o proporcionar mayor
información en relación a algún
aspecto recogido por el requisito.
 Evolución del Requisito
• Verdaderas modificaciones en la
implementación.
PCI DSS v2.0
Tipo de Cambios

4. 4
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
4
PCI DSS v2.0
 Implicados:
 comercio, proveedores, entidades adquirientes y emisores
 Account Data vs Cardholder data
 PreAutorización: PCI DSS también aplica a datos sensibles de autenticación
que son la pista completa en la banda magnética, el código de validación
CVV2/CVC2/CAV2/CID y el PIN/PIN Block
 PAN - mínimo dato que define la necesidad de PCI DSS
Cambios Generales

5. 5
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
5
PCI DSS v2.0
 Componentes de Sistema
 Entornos Virtuales: Máquinas virtuales, dispositivos de red virtuales e
incluso aplicaciones, escritorios e hipervisores.
 Segmentación de Red
 Segmentación física y lógica de la red.
 La segmentación es correcta si aislamos aquellos componentes de sistema
involucrados en el almacenamiento, procesamiento y transmisión de datos
de tarjetas, de los que no lo están.
 Muestreo
 Independiente por el auditor
 Localizaciones
 Componentes de sistemas
 No se toma muestra de requisitos
Cambios Generales

6. 6
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
6
PCI DSS v2.0
 Reestructuraciones de requisitos
 Reorganización de aspectos confusos y repetidos en distintos puntos de la
norma.
 Alineamiento de procedimientos de auditoría con
requisitos

7. 7
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
7
 No sólo FW o Routers
 Considerar otros componentes de sistema que implementen controles del
tráfico desde o hacia redes inseguras.
 Req 1.3.7
Place system components that store cardholder data (such as a database) in an internal network zone,
segregated from the DMZ and other untrusted networks.
 Requisito aplica a cualquier tipo de almacenamiento de datos de tarjetas y
no sólo a bases de datos.
PCI DSS v2.0
Req 1: Instalar y mantener un cortafuegos y su configuración

8. 8
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
8
 Req 2.2.1
Implement only one primary function per server to prevent functions that require different security levels
from co-existing on the same server.
 El objetivo de este requisito es la no coexistencia de funcionalidades que
requieran diferentes niveles de seguridad .
 Cada sistema virtualizado debe implementar una única función primaria.
PCI DSS v2.0
Req 2: No emplear parámetros de seguridad por defecto

9. 9
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
9
 Req 3.2
Do not store sensitive authentication data after authorization (even if encrypted).
 Entidades Emisoras: Pueden almacenar información sensible de
autenticación si existe la debida justificación por necesidad del negocio y,
por descontado, si estos datos son almacenados de forma segura.
 Req 3.4
Render PAN unreadable anywhere it is stored.
 Uso Combinado de Hash y Truncado: Se requiere implementar medidas de
seguridad adicionales para que no se pueda hacer una correlación entre el
hash y el dato truncado que permita obtener el PAN completo.
 No se puede utilizar la técnica de hashing para substituir la parte truncada
del PAN
PCI DSS v2.0
Req 3: Proteger los datos almacenados de tarjetas

10. 10
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
10
 Gestión de claves – concepto de Criptoperiodo
 Por ejemplo, un período de tiempo o una cantidad total de texto cifrado
generado por la clave a cambiar.
 Req 3.6.6
If manual clear-text cryptographic key management operations are used, these operations must be
managed using split knowledge and dual control.
 Limita la necesidad del split knowledge y el control dual a aquellas
operaciones de gestión de claves que se hagan en claro y que se realicen
manualmente.
 Req 3.6.8
Requirement for cryptographic key custodians to formally acknowledge that they understand and accept
their key-custodian responsibilities.
 Aceptación formal también aceptada en formato electrónico
PCI DSS v2.0
Req 3: Proteger los datos almacenados de tarjetas

11. 11
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
11
 Se aclara que el antivirus debe generar registros de
auditoría
 Protocolo WEP no es aceptado (30 Junio 2010)
PCI DSS v2.0
Req 4: Cifrar la transmisión de datos de tarjeta en redes públicas
abiertas
Req 5: Usar y actualizar regularmente software antivirus

12. 12
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
12
 Req 6.2
Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.
 30 Junio 2012: nuevas vulnerabilidades clasificadas según el riesgo que
introducen y basándose en las buenas prácticas definidas por la industria
como por ejemplo CVSS y/o siguiendo las clasificaciones que proporcionan
los proveedores del software afectado por la vulnerabilidad.
 Estructura de los requisitos 6.3, 6.4 y 6.5
Req 6.3: Develop software applications in accordance with PCI DSS
Req 6.4: Follow change control processes and procedures
Req 6.5: Develop applications based on secure coding guidelines
 Facilitar entendimiento
 Eliminar redundancias
 Agrupar conceptos: aplicaciones internas/externas, Web/No Web.
PCI DSS v2.0
Req 6: Desarrollar y mantener de forma segura sistemas y
aplicaciones

13. 13
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
13
 Req 7.1.3
Requirement for a documented approval by authorized parties specifying
required privileges.
 En lugar de requerir un formulario firmado por dirección
PCI DSS v2.0
Req 7: Restringir el acceso a la información de tarjetas
Req 8: Asignar IDs únicos
 Autenticación de 2 factores
 Es diferente de utilizar
autenticación de 1 factor 2 veces

14. 14
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
14
 Aclaraciones menores para los términos
 Onsite Personnnel
 Visitor
 Media
PCI DSS v2.0
Req 9: Restringir el acceso físico a datos de tarjetas

15. 15
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
15
 Se detalla más los requisitos relacionados con el uso de
sincronización de tiempo.
 No se limita a NTP
 Concreta como debe ser y estar protegida la arquitectura de sincronización.
PCI DSS v2.0
Req 10: Auditar y monitorizar todos los accesos a los recursos de red y
datos de tarjetas

16. 16
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
16
PCI DSS v2.0
 Escaneos Wifi
 Necesidad de disponer de un proceso documentado
 Métodos adicionales: Inspección física o tecnologías NAC.
 Escaneos de Vulns Trimestrales Internos
 Consideraciones para determinar cuando un escaneo se considera válido:
El escaneo será válido si se cumple una de las siguiente condiciones:
1. Todas las vulnerabilidades (a excepción de falsos positivos) han sido
solucionadas
2. Se han solucionado las vulnerabilidades “altas” siguiendo el proceso
de clasificación en base al riesgo (no esperamos a 30/6/12)
 IDS/IPS
 Monitorización del tráfico a nivel de perímetro y en puntos considerados
críticos.
Req 11: Testear de forma regular la seguridad de los sistemas y
procesos

17. 17
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
17
 Análisis de Riesgos
 Aclaración de que se considera AR formal
 Ejemplos: Octave, ISO27005, NIST SP 800-30
 Req 12.3.10
For personnel accessing cardholder data via remote-access technologies, prohibit copy, move, and
storage of cardholder data onto local hard drives and removable electronic media, unless explicitly
authorized for a defined business need.
 Se permite en el acceso remoto a datos de tarjeta copiar, mover o almacenar
en local y medios removibles.
 Con Justificación en base a una necesidad de negocio
 Protegiendo la información según establece PCI DSS.
Req 12: Mantener una política que gestione la seguridad de la
información
PCI DSS v2.0

18. 18
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
18
 Aclaraciones
 Cambios principalmente del texto
con el objetivo de explicar mejor el
objetivo deseado con el requisito.
 Guía Adicional
 Introduce ejemplos o definiciones
que permiten aumentar el
entendimiento o proporcionar mayor
información en relación a algún
aspecto recogido por el requisito.
 Evolución del Requisito
• Verdaderas modificaciones en la
implementación.
PA DSS v2.0
Tipo de Cambios

19. 19
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
19
PA DSS v2.0
 PA DSS por si mismo no hace cumplir PCI DSS
 Desplegada en un entorno cumplidor PCI DSS.
 Aplicación desplegada según la Guía de Implementación que proporciona el
proveedor de la aplicación.
 Ámbito de Aplicación de PA DSS
 Se aclara que PA DSS No aplica si la aplicación se ha desarrollado y ha sido
vendida a un solo cliente.
 Aplicabilidad en aplicaciones residentes en Terminales
Hardware
Payment applications designed to operate on hardware terminals (also known as a standalone or
dedicated POS terminal) may undergo a PA-DSS review if the vendor wishes to achieve validation and if
PA-DSS compliance requirements can be met.
 NO es Obligatorio: Si el vendedor desea alcanzar la certificación con PA DSS.
 ¿Qué puede impulsar a la necesidad de certificación?: Necesidad de
negocio (Ej: un contrato lo requiere), obligación (ej: una marca lo solicita).
Cambios Generales

20. 20
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
20
PA DSS v2.0
 Laboratorio de Pruebas
 El PA QSA debe tener acceso a un laboratorio donde se realizará el proceso
de validación de la aplicación
 El PA QSA debe validar una instalación limpia (no se puede reutilizar una
instalación ya existente) del entorno de laboratorio para asegurar que simula
lo más fielmente posible un situación real y que el entorno de laboratorio no
ha sido manipulado por el vendedor.
Cambios Generales

21. 21
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
21
PA DSS v2.0
 Reestructuraciones de requisitos
 Menos referencias a la Norma PCI DSS. Se incluye en la propia norma PA DSS
 Se fusionan los requerimientos 10 y 11 para eliminar redundancias
 Alineamiento con las modificaciones introducidas en la
norma PCI DSS v2.0

22. 22
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
22
 Req 2.5
Payment application must protect any keys used to secure cardholder data against disclosure and
misuse.
 También afecta a las claves utilizadas para proteger las claves de cifrado de
datos (key-encrypting keys).
 Req 2.6
Payment application must implement key management processes and procedures for cryptographic keys
used for encryption of cardholder data
 Se solicita que la guía de implementación contenga instrucciones para las
funciones de gestión de claves de cifrado.
 Req 2.7
Render irretrievable any cryptographic key material or cryptogram stored by previous versions of the
payment application, in accordance with industry-accepted standards.
 Se acepta como válido la eliminación de forma segura (irrecuperable) de la
clave que protege la clave de cifrar los datos (key-encryption key).
PA DSS v2.0
Cambios Destacables

23. 23
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
23
 Req 3.1
The payment application must support and enforce the use of unique user IDs and secure authentication
for all administrative access and for all access to cardholder data. Secure authentication must be
enforced to all accounts, generated or managed by the application, by the completion of installation
and for subsequent changes after installation.
 Afecta a todas la cuentas gestionadas por la aplicación y no sólo durante la
instalación sino que también en cambios posteriores.
 Req 4.4
Payment application must facilitate centralized logging
 Nuevo Requerimiento
 Las aplicaciones de pago deben facilitar la centralización de logs de
PA DSS v2.0
Cambios Destacables

24. 24
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
24
 Req 5
 Ha sufrido una gran reestructuración de los requisitos como consecuencia
de la propia reestructuración del requisito 6 en PCI DSS v2.0.
 El concepto de entorno de producción no es aplicable para el objetivo de PA
DSS.
 Req 7.1
Software vendors must establish a process to identify and assign a risk ranking to newly discovered
security vulnerabilities and to test their payment applications for vulnerabilities. Any underlying
software or systems that are provided with or required by the payment application (for example, web
servers, third-party libraries and programs) must be included in this process.
 Evolución del requisito
 Se añade la necesidad de clasificar las vulnerabilidades en base al riesgo y
para PA DSS debe implementarse ya. No es opcional hasta el 30/6/2012
como en PCI DSS v2.0.
PA DSS v2.0
Cambios Destacables

25. 25
Haga clic para modificar el estilo de
título del patrón
• Haga clic para modificar el estilo de texto del
patrón
– Segundo nivel
• Tercer nivel
– Cuarto nivel
PREGUNTAS