cómo cumplir con pci dss sin nombrarla - isecauditors.com · • fundador de internet security...

Cómo cumplir con

PCI DSS… sin

nombrarla

Daniel Fernández Bleda @DeFerBle Internet Security Auditors @ISecAuditors PeruHackCon ‘14 – 21/noviembre/2014 –UPC

• Quién soy • Conceptos básicos • Dudas recurrentes • ¿Realmente se necesita? • Incidentes <-> Requerimientos • Consecuencias reales • Marcos regulatorios

ÍNDICE: PCI DSS, ¿cómo cumplir sin nombrarla?

Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC 2

• Fundador de Internet Security Auditors el año 2001, empresa de Servicios de CiberSeguridad referente en España.

• Ingeniero Superior en Informática por la Univ. Autónoma de Barcelona (España).

• OPST, OPST/A Trainer, CHFI, CHF|I Instructor • CISM, CISA, CISSP, ISO 27001 Lead Auditor • Internet Security Auditors es QSA, PA-QSA y

ASV desde el año 2007 y referente en España es Adaptaciones y Certificaciones exitosas en normas PCI.

Quién soy


Y llevo mucho “evangelizando” sobre PCI DSS

Quién soy


• Los estándares PCI* son un conjunto de normas gestionadas por el PCI SSC.

• El PCI SSC lo crean el año 2009 cinco marcas de tarjetas: VISA, MC, AMEX, JCB y Discover.

• Las normas dentro de la “familia” PCI son: o PCI DSS: para empresas que tratan/transmiten/almacenan. o PA-DSS: para aplicaciones de pago en entornos PCI DSS. o PTS: para dispositivos que capturan los datos,cifran, etc. o P2PE: para soluciones y empresas que cifran P2P o PIN: para entidades y empresas que tratan los PIN o Card Production: para fabricantes/personaliz. de tarjetas.

Dudas recurrentes sobre las normas PCI


• ¿Cuántos han comprado y leído la norma?

• ¿Cuántos conocen los niveles de cumplimiento de la norma?

• ¿Cuántos saben encontrar en Internet qué bancos y comercios están certificados?

• ¿Cuántos reconocerían el logo oficial del PCI SSC para las empresas certificadas?

Conceptos básicos


Conceptos básicos

Algo no se está haciendo bien

¡Y el culpable no será el cristal! Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC 7

• Todos los documentos y estándares del PCI SSC son gratuitos y descargables sin costo.

• La norma no tiene niveles de cumplimiento: se cumple o no se cumple.

• No es posible saber que comercios o bancos cumplen con PCI DSS porqué no existe un listado oficial.

• El PCI SSC rechazó crear un logo oficial para las empresas auditadas: para evitar confusión.

Conceptos básicos


• Define los requerimientos de seguridad que debe cumplir cualquier organización (sea del tipo que sea) que trata, transmite o almacena datos de tarjetas de pago.

• La norma es agnóstica del tipo de negocio. • La norma es agnóstica de la tecnología

empleada. • La norma tiene un cumplimiento binario: se es

cumplidor o no se es. No tiene “grises” o “cumplimientos parciales”.

Dudas recurrentes sobre qué es PCI DSS


• La norma no define cómo demostrar el cumplimiento a terceros. Esto lo determinan las marcas de tarjetas de pago.

• Sólo empresas homologadas como QSA pueden llevar a cabo auditorías oficiales y reconocidas.

• PCI DSS no es la ISO/IEC 27001:2013, tratarla como similares es un error.

• La Auditoría tiene el objetivo de confirmar el cumplimiento no es la mejor herramienta para identificar incumplimientos pre-implantación.

Dudas recurrentes


• Yo no guardo los datos de tarjetas: no necesito cumplir.

• Ya guardo los datos cifrados: ya cumplo. • Ya he instalado el producto X y me han dicho

que con eso ya cumplo. • Ya hago los escaneos trimestrales: ya cumplo. • No soy nivel 1 así que puedo cumplir más

fácilmente. • He delegado ciertos procesos de pagos en un

tercero: que cumpla él, yo me olvido del tema.

“Fails” habituales


El objetivo principal de la norma es reducir el fraude asociado al compromiso de datos de tarjetas. El fraude que se produce tras un compromiso tiene consecuencias directas a los ciudadanos:

• Cuando se realizan operaciones fraudulentas en comercios, éstos deben asumir el fraude.

• Cuando se realizan operaciones fraudulentas en entidades financieras, éstas deben asumir el fraude.

• Cuando se dejan de pagar impuestos con esas actividades, los estados dejan de recaudar dinero.

¿Por qué cumplir con PCI DSS?


Los bancos, los comercios y los estados han de trasladar ese fraude a clientes y ciudadanos:

• Los bancos deberán incrementar comisiones asociadas al fraude.

• Los comercios el precio de los productos para compensar pérdidas.

• Los estados no incrementan inversiones en servicios a los ciudadanos si no se recauda.

Que todo el “ecosistema” de afectados cumpla con PCI DSS nos ha de preocupar a todos:

TODOS perdemos y TODOS ganamos



Según el informe de LACNIC del 2013 sobre el Ciberdelito en América Latina y el Caribe del Proyecto Amparo:

• El comercio electrónico en la región produce USD4.300 MM.

• Unas cifras cautelosas implican que el 1% es fraude directo, es decir, USD 430 MM.

• Un 1,8% de compras están relacionadas con actividades fraudulentas.



Pero los incidentes tienen un impacto mucho mayor para las organizaciones y estados:



Pero ¿quién o qué hay detrás de los compromisos de datos de pago?

• Existe un importante mercado negro que comercia con todo tipo de productos no tangibles: no son armas, no son drogas, no son seres humanos.

Es INFORMACIÓN

• Uno de los más valorados son los datos de pago.

• En el “deep web” es fácil encontrar vendedores y comprar estos productos ilegales con “impunidad”.

¿Es esto ciencia ficción?


El principal error es pensar que “esto le pasa siempre a aquel, que es un incauto” “yo uso muy bien las herramientas tecnológicas” “yo se a quién le doy mis datos y qué hace con ellos”

Es un error, porqué los datos de pago de las tarjetas que empleamos pueden estar en cientos de lugares por un uso incorrecto que otros hacen de éstos datos.

Mercado negro


Mercado negro (red Tor)


Lo más importante de los incidentes es analizar por qué se produjeron para que no se repitan. La cuestión es:

• Se están repitiendo de forma cíclica: ‘03-’04 vs ‘13-’14. • Ahora se dispone de un marco claro de referencia,

PCI DSS, pero en algunos casos se emplea de forma incorrecta o laxa: falsa sensación de seguridad.

• Cumplir con PCI DSS es más que trabajo de un día. • Cumplir realmente con los requerimientos de PCI DSS

mitiga enormemente las vulnerabilidades.

Veamos detalles de algunos casos.

Incidentes reales de compromiso de datos de pago

Nombre: Target Brands, Inc. Tipo Empresa: Retail Fecha de publicación: 19 de diciembre de 2013 Fecha de compromiso: 27/11-15/12 de 2013 Cantidad de datos comprometidos: 40->110MM Proceso del Ataque (según la propia HPS): 1. Proveedor de servicios HVAC es atacado 2. Se aprovecha su acceso a la red. 3. Se escala a la red de producción. 4. Se troyanizan los POS con BlackPOS. 5. Se capturan, agrupan y extraen los datos.

Incidente 1


Qué falló (según Target): Su proveedor de servicios de HVAC no cumplió con las medidas de seguridad adecuadas. Qué parece que falló según PCI DSS:

¿Cuánto tiempo tenemos?

Veamos alguno de ellos……

Incidente 1


1. Segregación y control de tráfico de red. Requerimientos 1.2: Build firewall and router

configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.

2. Falta de herramientas AV en los POS. Requerimientos 5.1: Deploy anti-virus software on all

systems commonly affected by malicious software (particularly personal computers and servers).

Incidente 1


3. Falta de actualización de los POS. Requerimientos 6.2 Ensure that all system

components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

4. Bajo conocimiento de responsabilidades. Requerimiento 12.4 Ensure that the security policy and procedures clearly define information security responsibilities for all personnel.

Incidente 1


5. IDS sin procesos de gestión de alertas. Requerimiento 12.10 Implement an incident response

plan. Be prepared to respond immediately to a system breach.

Incidente 1


Nombre: Adobe, Inc. Tipo Empresa: Productos Software y Servicios Fecha de publicación: 13 de octubre de 2013 Fecha de compromiso: ¿agosto-septiembre? Cantidad de datos comprometidos: 38->150MM Proceso del Ataque (sin información): 1. Los malos acceden a sus sistemas. 2. Esos sistemas tienen el código fuente. 3. Se escala a la red de producción. 4. Roban el código fuente de sus productos. 5. Roban una DB de pwds/datos de clientes.

Incidente 2


Qué falló (según Adobe): ???. Qué parece que falló según PCI DSS:


Veamos alguno de ellos……

Incidente 2


1. La criptografía empleada era débil/absurda. Requerimientos 3.4: Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches: o One-way hashes based on strong cryptography, (hash must

be of the entire PAN) o Truncation (hashing cannot be used to replace the truncated

segment of PAN) o Index tokens and pads (pads must be securely stored) o Strong cryptography with associated key-management

processes and procedures.

Incidente 2


Para que usar hash si puedo cifrar con algoritmos del “siglo XX”

Incidente 2


Nombre: Heartland Payment Systems Tipo Empresa: Procesador de Pagos Fecha de publicación: 20 de enero de 2009 Fecha de compromiso: finales de 2008 Cantidad de datos comprometidos: 160MM ejem..

Proceso del Ataque (fuentes oficiales): 1. SQL Injection 2. Escalada de Privilegios a red de Prod. 3. Troyanización de sistemas 4. Sniffing de datos por la red.

Incidente 3


Qué falló (según TD Bank): Su QSA no detectó la vulnerabilidad en las revisiones de seguridad. Qué parece que falló según PCI DSS:


Incidente 3


1. Segregación y control de tráfico de red. Requerimientos 1.2: Build firewall and router configurations that restrict connections between untrusted networks and any system components in the cardholder data environment.

2. Falta de securización de sistemas. Requerimientos 2.2: Develop configuration standards for all system components. Assure that these standards address all known security vulnerabilities and are consistent with industry-accepted system hardening standards.

Incidente 3


3. Falta de protección a nivel de Capa 7. Requerimiento 6.6: For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks […].

4. Débil revisión diaria de eventos de seguridad. Requerimiento 10.6: Review logs and security events for all system components to identify anomalies or suspicious activity.

Incidente 3


5. Débil configuración de los sistemas IDS/IPS. Requerimiento 11.4 Use intrusion-detection and/or

intrusion-prevention techniques to detect and/or prevent intrusions into the network. Monitor all traffic at the perimeter of the cardholder data environment as well as at critical points in the cardholder data environment, and alert personnel to suspected compromises.

Incidente 3


6. Falta de controles de Integridad de ficheros. Requerimiento 11.5 Deploy a change-detection

mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

Incidente 3


En toda América ha impactado el problema de la adopción del CHIP & PIN (EMV): eso era una cosa de Europa para ellos. ;)

Los reguladores de la región han forzado la adopción “urgente” de EMV y de prácticas de seguridad, extraídas de las ISO/IEC 27001 y de PCI DSS, en la mayoría de casos.

El caso de Perú y la SBS mediante el:

“Reglamento de Tarjetas de Crédito y Débito”

¿Qué hacen los estados al respecto?


Resolución S.B.S. Nº 6523 -2013 Artículo 18°.- Medidas en materia de seguridad de la información

• Son exigibles, a las empresas, las normas vigentes emitidas por la Superintendencia sobre gestión de seguridad de la información y de continuidad del negocio.

• Asimismo, en torno al almacenamiento, procesamiento y transmisión de los datos de las tarjetas que emitan, las empresas deberán implementar los siguientes controles específicos de seguridad.



1. Implementar y mantener la configuración de cortafuegos o firewalls, enrutadores y [...] 2. Implementar políticas para evitar el uso de clave secreta y parámetros de seguridad […]. 3. Implementar políticas de almacenamiento, retención y de eliminación de datos […]. 4. Implementar mecanismos de cifrado para la transmisión de los datos del usuario en redes públicas.



5. Implementar y actualizar software y programas antivirus en computadores y servidores. 6. Mantener sistemas informáticos y aplicaciones seguras; para el caso de software provisto por terceros, establecer procedimientos para […]. 7. Implementar políticas que restrinjan el acceso a los datos de los usuarios solo al personal autorizado […]. 8. Implementar políticas de asignación de un identificador único a cada persona que acceda a través de software a los datos de los usuarios.



9. Implementar controles de acceso físico para proteger los datos de los usuarios, restringiéndolo únicamente a personal […]. 10. Registrar y monitorear todos los accesos a los recursos de red y a los datos de los usuarios. 11. Efectuar análisis de vulnerabilidades periódicos a la red interna y pruebas de penetración externas e internas […]. 12. Implementar lineamientos y procedimientos de seguridad de la información específicos, incluyendo un programa formal […].



Es decir … qué implementen y cumplan con PCI DSS

¿Por qué no llamarlo por su nombre?

Es necesario que la SBS defina las consecuencias de no cumplir con

PCI DSS. Pero quedan muchas empresas fuera de la responsabilidad directa de la SBS



• PCI DSS es un estándar imprescindible en un mundo donde los datos de pago se mueven en volúmenes tan importantes.

• Las marcas de tarjeta deben replantear sus responsabilidades y la de todos los players: no se cumple con PCI DSS ni donde se dice que se cumple.

• Los usuarios deben conocer estos estándares para ser capaces de exigir su cumplimiento igual que leyes de protección de datos de carácter personal o de privacidad.

Conclusiones (I)


• Los reguladores están haciendo un esfuerzo en unificar criterios en la seguridad en medios de pago pero han de unificar criterios en las exigencias: PCI DSS es un marco válido.

• Incrementando la transparencia sobre el cumplimiento de los players afectados se conseguirá aumentar el cumplimiento global.

• Los auditores QSA hemos de ser exigentes con nosotros mismos cuando asesoramos y auditamos: una auditoría “laxa” no es ningún “favor” para el auditado es una “amenaza”.

Conclusiones (II)


PREGUNTAS


[email protected] @DeFerBle

http://www.isecauditors.com

http://facebook.com/isecauditors

http://twitter.com/isecauditors

https://www.linkedin.com/company/internet-security-auditors

https://plus.google.com/+Isecauditors

https://www.youtube.com/user/ISecAuditors

Más información…


ÍNDICE: PCI DSS, ¿cómo cumplir sin nombrarla?

Muchas gracias

Daniel Fernández Bleda @DeFerBle Internet Security Auditors @ISecAuditors PeruHackCon ‘14 – 21/noviembre/2014 –UPC

cómo cumplir con pci dss sin nombrarla - isecauditors.com · • fundador de internet security...

Documents