Novedades PCI DSS v 2.0 y PA-DSS v 2.0.

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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



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



patrón

– Segundo nivel

• Tercer nivel

– Cuarto nivel

PREGUNTAS

Novedades PCI DSS v 2.0 y PA-DSS v 2.0.

Technology

Transcript of Novedades PCI DSS v 2.0 y PA-DSS v 2.0.