PCI DSS se ha convertido estos últimos años en una de las normas más nombradas dentro de los mensajes de ventas relacionadas con Seguridad TIC y el cumplimiento normativo. Pero, aun así, se siguen produciendo incidentes de seguridad que han situado el año 2013 en uno donde mayor cantidad de datos de pago se han comprometido y las expectativas son que el 2014 todavía lo supere. La pregunta es ¿es realmente útil PCI DSS para impedir esto? La respuesta podría ser otra pregunta ¿se está realmente implantando correctamente PCI DSS? En esta presentación se tratan estos aspectos con el particular punto de vista del Perú y la regulación emitida por su Superintendencia Bancaria y de Seguros.

1. Cómo cumplir con PCI DSS… sin nombrarla
Daniel Fernández Bleda @DeFerBle
Internet Security Auditors @ISecAuditors
PeruHackCon ‘14 – 21/noviembre/2014 –UPC

2. •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

3. •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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
3

4. Y llevo mucho “evangelizando” sobre PCI DSS
Quién soy
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
4

5. •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:
oPCI DSS: para empresas que tratan/transmiten/almacenan.
oPA-DSS: para aplicaciones de pago en entornos PCI DSS.
oPTS: para dispositivos que capturan los datos,cifran, etc.
oP2PE: para soluciones y empresas que cifran P2P
oPIN: para entidades y empresas que tratan los PIN
oCard Production: para fabricantes/personaliz. de tarjetas.
Dudas recurrentes sobre las normas PCI
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
5

6. •¿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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
6

7. 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

8. •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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
8

9. •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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
9

10. •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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
10

11. •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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
11

12. 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?
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
12

13. 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
¿Por qué cumplir con PCI DSS?
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
13

14. 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.
¿Por qué cumplir con PCI DSS?
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
14

15. Pero los incidentes tienen un impacto mucho mayor para las organizaciones y estados:
¿Por qué cumplir con PCI DSS?
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
15

16. 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?
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
16

17. 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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
17

18. Mercado negro (red Tor)
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
18

19. 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

20. 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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
20

21. 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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
21

22. 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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
22

23. 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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
23

24. 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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
24

25. 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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
25

26. Qué falló (según Adobe): ???.
Qué parece que falló según PCI DSS:
¿Cuánto tiempo tenemos?
Veamos alguno de ellos……
Incidente 2
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
26

27. 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:
oOne-way hashes based on strong cryptography, (hash must be of the entire PAN)
oTruncation (hashing cannot be used to replace the truncated segment of PAN)
oIndex tokens and pads (pads must be securely stored)
oStrong cryptography with associated key-management processes and procedures.
Incidente 2
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
27

28. Para que usar hash si puedo cifrar con algoritmos del “siglo XX”
Incidente 2
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
28

29. 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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
29

30. 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:
¿Cuánto tiempo tenemos?
Incidente 3
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
30

31. 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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
31

32. 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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
32

33. 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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
33

34. 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
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
34

35. 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?
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
35

36. 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.
¿Qué hacen los estados al respecto?
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
36

37. 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.
¿Qué hacen los estados al respecto?
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
37

38. 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.
¿Qué hacen los estados al respecto?
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
38

39. 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 […].
¿Qué hacen los estados al respecto?
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
39

40. 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
¿Qué hacen los estados al respecto?
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
40

41. •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)
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
41

42. •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)
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
42

43. PREGUNTAS
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
43
dfernandez@isecauditors.com
@DeFerBle

44. 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…
Daniel Fernández Bleda @DeFerBle – Internet Security Auditors @ISecAuditors – PeruHackCon ‘14 – 21/noviembre/2014 –UPC
44

45. Í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