Auditoría de Sistemas y reglamentacion PCI

993 visualizaciones

Publicado el

Publicado en: Tecnología
0 comentarios
1 recomendación
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
993
En SlideShare
0
De insertados
0
Número de insertados
8
Acciones
Compartido
0
Descargas
26
Comentarios
0
Recomendaciones
1
Insertados 0
No insertados

No hay notas en la diapositiva.

Auditoría de Sistemas y reglamentacion PCI

  1. 1. Mayo 29, 2013 Solineth Batista - Carlos Pretelt Luigi Ruiz - Ezequiel Vergara
  2. 2. PCI Security Standards Council Elementos para la alineación PCI DSS Requerimientos de PCI DSS Historia Actualizaciones e información adicional Cómo empezar PA DSS Requerimientos Gobernabilidad y cumplimiento Historia Futuro Estándares PCI
  3. 3. Quién debe cumplir con esta regulación Proceso de cumplimiento Asesores aprobados y fabricantes certificados Obligaciones de los comercios Comercios: Niveles Cuestiones a considerar de los comercios Qué se entiende por SP Proveedores de servicios: Niveles Entidades Adquirentes y Emisoras Desarrolladores de aplicaciones de pago Beneficios de cumplir con PCI
  4. 4. El Consejo de Estándares de Seguridad para la Industria de Tarjetas de Pago es un foro mundial abierto destinado a la formulación, mejora, almacenamiento, difusión y aplicación permanentes de las normas de seguridad para la protección de datos de cuentas. Su misión es aumentar la seguridad de los datos de cuentas de pago mediante la promoción de la educación y el conocimiento sobre las Normas de seguridad de la PCI (Industria de tarjetas de pago).
  5. 5. Hasta octubre de 2006: Cada marca de tarjetas tenía su propio programa de requerimientos de seguridad. Actividad descoordinada
  6. 6. En octubre de 2006, se forma el PCI SSC para coordinar y administrar los esfuerzos conjuntamente para combatir el robo de datos de titulares de tarjetas.
  7. 7. Significa Estándar de Seguridad de Datos para la Industria de Tarjeta de Pago. Este estándar ha sido desarrollado por un comité conformado por las compañías de tarjetas (débito y crédito) más importantes como una guía que ayude a las organizaciones que procesan, almacenan y/o transmiten datos de tarjetahabientes (o titulares de tarjeta), a asegurar dichos datos, con el fin de prevenir los fraudes que involucran tarjetas de pago débito y crédito.
  8. 8. Las compañías que procesan, guardan o trasmiten datos de tarjetas deben cumplir con el estándar o arriesgan la pérdida de sus permisos para procesar las tarjetas de crédito y débito (Perdida de franquicias), enfrentar auditorías rigurosas o pagos de multas. Los comerciantes y proveedores de servicios de tarjetas de crédito y débito, deben validar su cumplimiento al estándar en forma periódica.
  9. 9. La versión actual de la norma es la versión 2.0, lanzada el 26 de octubre de 2010. PCI DSS versión 2.0 debe ser adoptada por todas las organizaciones con datos de tarjetas de pago antes del 1 de enero de 2011 y desde el 1 de enero de 2012 todas las evaluaciones deben estar conforme a la versión 2.0 de la norma. PCI DSS versión 2.0 tiene dos requisitos nuevos y está en desarrollo de 132 cambios.
  10. 10. La siguiente tabla resume los diferentes puntos de la versión 1.2 de 1 de octubre de 2008, y especifica los 12 requisitos para el cumplimiento, organizados en seis grupos relacionados lógicamente, que se denominan "objetivos de control".
  11. 11. PCI DSS comenzó originalmente como cinco programas diferentes: Programa de Seguridad de la Información de Tarjetas Visa, Sitio de Protección de Datos MasterCard, Política Operativa de Seguridad de Datos American Express, Información y Cumplimiento Discover, y el Programa de Seguridad de Datos de JCB. Las intenciones de cada compañía fueron más o menos similares: crear un nivel adicional de protección para los emisores de tarjetas, asegurando que los comerciantes cumplan con los niveles mínimos de seguridad cuando se almacenan, procesan y transmiten datos de titulares de tarjetas.
  12. 12. En septiembre de 2006, el estándar PCI se actualizó a la versión 1.1 para proporcionar aclaraciones y revisiones menores a la versión 1.0. La versión 1.2 fue lanzada el 1 de octubre de 2008. La versión 1.1 el 31 de diciembre de 2008. La v1.2 no cambió los requisitos, sólo mayor claridad, una mayor flexibilidad, y se dirigió a la evolución de los riesgos /amenazas. En agosto de 2009, el PCI SSC anunció el paso de la versión 1.2 a la versión 1.2.1 para el propósito de hacer pequeñas correcciones encaminadas a crear más claridad y coherencia entre las normas y los documentos de apoyo.
  13. 13. El PCI SSC ha lanzado varias piezas complementarias de información para aclarar diversos requisitos. Estos documentos incluyen la siguiente: •Suplemento informativo: Requisito 11.3 Pruebas de Penetración •Suplemento informativo: Requisito 6.6 revisiones de código y cortafuegos de aplicación Clarificado •Navegando por el PCI DSS - Comprensión del objetivo de los requisitos •Suplemento informativo: PCI DSS Directrices inalámbricas
  14. 14. Documento titular de flujo de datos - Uno de los primeros pasos en el cumplimiento de PCI es documentar el flujo de los datos de los tarjetahabientes. Los flujos de datos de los tarjetahabientes entre y a través de aplicaciones, sistemas y dispositivos de red. Es muy importante documentar el flujo de todos los datos de los tarjetahabientes antes de comenzar cualquier actividad de evaluación.
  15. 15. Desarrollar un inventario del sistema - un inventario de todos los sistemas que almacenan, procesan y / o transmiten datos de tarjetas debe mantenerse. La siguiente información, como mínimo, se debe mantener en el inventario: •Nombre del sistema •Datos de tarjetas almacenados (campos de lista) •Motivo de almacenamiento •El período de retención •Mecanismo de protección (por ejemplo, hashing, encriptación, o truncamiento)
  16. 16. Es de señalar que cuando se está desarrollando el sistema de inventario se debe dividir las aplicaciones y componentes del sistema en categorías para efectos de la definición del alcance. •Categoría 1 aplicaciones y componentes del sistema: Aplicaciones y sistemas que directamente almacenan, procesan o transmiten datos de tarjetas o se encuentran en la misma red que dichas aplicaciones y sistemas •Categoría 2: Componentes del sistema: Componentes del sistema que apoyan el entorno (es decir, Active Directory, NTP, DNS, Anti-virus, los servidores de parches, etc) •Categoría 3 Componentes del sistema: Todos los demás componentes del sistema que no sean de Nivel 1 y Nivel 2
  17. 17. Las Normas de Seguridad de Datos para las Aplicaciones de Pago. Anteriormente conocido como las Mejores Prácticas de Aplicaciones de Pago (PABP), es el estándar de seguridad global creado por el Payment Card Industry Security Standards Council (PCI SSC). PA-DSS se puso en práctica en un esfuerzo por proporcionar un estándar para los proveedores de software que desarrollan aplicaciones de pago.
  18. 18. La norma tiene por objeto evitar que las aplicaciones de pago desarrolladas por cuenta de terceros practiquen el almacenamiento seguro de datos prohibidos, incluyendo banda magnética, CVV2 o PIN. En ese proceso, la norma también establece que los proveedores de software que desarrollan aplicaciones de pago deben asegurarse de que estas son compatibles con la Norma de Seguridad de Datos de la Industria de Tarjetas de Pago (PCI DSS).
  19. 19. Para que una aplicación de pago se considere compatible con PA-DSS, los proveedores de software deben asegurarse de que su software incluye las siguientes 14 protecciones
  20. 20. 7. Someter a prueba las aplicaciones de pago para identificar vulnerabilidades. 10. Implementar actualizaciones de software remotas seguras. 14. Mantener la documentación de instrucción y programas de formación para clientes, revendedores e integradores.
  21. 21. PCI SSC ha compilado una lista de las aplicaciones de pago que han sido validadas como conformes con PA-DSS, para reflejar quienes cumplen en la medida que se desarrollan. La creación y aplicación de estas normas se apoya en la actualidad con PCI SSC a través de los Asesores de Seguridad Calificados de Aplicaciones de Pago (PA-QSA). PA-QSA que aplican revisiones periódicas a las aplicaciones de pago que ayudan a los proveedores de software a asegurarse que las aplicaciones son compatibles con los estándares PCI.
  22. 22. Gobernado originalmente por Visa Inc., bajo el nombre de PABP, PA-DSS se puso en marcha el 15 de abril de 2008 y fue actualizado el 15 de octubre de 2008. PA-DSS se distinguió a través de la "versión 1.1" y "versión 1.2".
  23. 23. El futuro de estas normas es algo vago, con la atención del Congreso Estadounidense que da lugar a la posibilidad de la intervención gubernamental. En cualquier caso, el cumplimiento de las normas puede resultar costoso y consume tiempo para los proveedores de software, con el gasto actual de la certificación PA-DSS superando a otros métodos de cumplimiento. Dado el costo de cumplimiento y certificación, las alternativas actuales o aún indeterminadas podrían surgir en el mercado de cumplimiento de las normas PCI. Visa USA anunció un impulso más agresivo en este tipo de tecnología (chip y pin) en agosto de 2011. Visa Press Release
  24. 24. El PCI SSC ha publicado materiales que aclaran aún más PA-DSS, incluyendo las siguientes: •Requisitos PA-DSS y procedimientos de evaluación de seguridad. •Los cambios de las normas anteriores. •Guía de programación General para QSA.
  25. 25. Cualquier compañía (comercios, procesadores, entidades adquirentes, emisoras, proveedores de servicio) que almacene, procese, o transmita información de un tarjetahabiente debe cumplir con PCI y realizar auditorías periódicas.
  26. 26. Participantes en la regulación PCI Aplicaciones de pago
  27. 27. Dependiendo del tipo de compañía se requerirá de pasar por una auditoría PCI cada año o completar un cuestionario de autoevaluación con el fin de poder validar el cumplimiento de dicha auditoría. Además de esta actividad, se tendrán que presentar los resultados trimestrales del análisis de vulnerabilidades del perímetro de red (el cual tiene que ser realizado por un fabricante debidamente certificado para la realización de auditorías PCI), el cual es evidencia del desarrollo de esta actividad. Se busca con estas pruebas de vulnerabilidad demostrar que su compañía posee las mejores prácticas en lo relacionado con la remedición y la gestión de vulnerabilidades. Este será, pues, el objetivo principal de la auditoría PCI.
  28. 28. Verificaciones técnicas de seguridad PCI DSS requiere la realización de 5 tipos de verificaciones técnicas de seguridad periódicas a la infraestructura de datos de tarjetas
  29. 29. Verificaciones técnicas de seguridad
  30. 30. PCI Co, ahora controla qué compañías le son permitidas conducir una auditoría PCI. Estas compañías, conocidas oficialmente como •Qualified Security Assessor Companies (QSACs), son organizaciones que han sido calificados por el Council para que sus empleados puedan evaluar el cumplimiento de la norma PCI DSS. Estos deben recorrer un proceso de aplicaciones y calificaciones con el fin de demostrar su cumplimiento a través de la calidad de sus procesos operativos y administrativos.
  31. 31. Los QSACs también deben invertir en entrenamiento y certificación del personal con el fin de construir un equipo de: Qualified Security Assesors (QSAs), cuyo objetivo principal es llevar a cabo una evaluación de una empresa que maneja los datos de tarjetas de crédito en contra de los objetivos de control de alto nivel de la Norma de Seguridad de Datos PCI (PCI DSS). Approved Scanning Vendor (ASV), son organizaciones que validan el cumplimiento de determinados requisitos DSS mediante la realización de análisis de vulnerabilidades de Internet a las que se enfrentan entornos de comerciantes y prestadores de servicios.
  32. 32. Asesores de Seguridad Calificados(QSA)
  33. 33. Estas compañías deben recorrer un proceso similar al de los QSAC. La diferencia radica en que en el caso de los QSAC, los cuales deben atender entrenamientos periódicos y anuales, los ASVs deben enviar un informe de resultados contra un perímetro de red. Una compañía puede elegir ser tanto QSAC como ASV, lo que le permitirá ser un único fabricante en capacidad de ofrecer la auditoría completa PCI.
  34. 34. En general, las marcas de tarjetas (VISA, MASTER, JCB, AMEX, DISCOVER) definen unos niveles de cumplimiento para los comercios. Para cada nivel de cumplimiento de los comercios, se establecen una serie de obligaciones. En general, se definen 4 niveles para el caso de los comercios, atendiendo principalmente al número de transacciones por año.
  35. 35. Implica la realización de una Auditoria anual por parte de un QSA (Qualified Security Assesor) que rellenaría un ROC (Report Of Compliance) que se enviaría a cada una de las marcas. En esta auditoría se realiza un estudio exhaustivo del estado de cumplimiento del comercio, así como diversos controles de seguridad (Escaneos de red trimestrales por un ASV Approved Scanning Vendor). Se entiende como comercio de Nivel-1 a los que procesen el siguiente número de transacciones/año: •Más de 6 millones de transacciones VISA, MASTER o DISCOVER. •Más de 2,5 millones de transacciones AMEX •Más de 1 millón de transacciones JCB Adicionalmente, se consideran también comercios Nivel-1 a aquellos que han sufrido un ataque en el que se hayan puesto en compromiso datos de tarjeta o cualesquiera que una marca considere debe ser de Nivel-1.
  36. 36. Se entiende como comercio de Nivel-2 a los que procesen el siguiente número de transacciones/año: •Entre 1 y 6 millones de transacciones VISA, MASTER o DISCOVER. •Entre 50K y 2,5 millones de transacciones AMEX •Menos de 1 millón de transacciones JCB En este nivel, los comercios no están obligados a llevar a cabo una auditoria PCI-DSS anual; en su lugar, deben rellenar un formulario de autoevaluación conocido como SAQ (Self-Assessment Questionnarie). Sin embargo, las cosas no son tan fáciles; En el caso de MASTER, desde Junio de 2012 es de obligado cumplimiento que si quieren presentar un SAQ, éste sea rellenado por un persona que tenga el certificado PCI SSC ISA (Internal Security Auditor) y para ello, deberá asistir a los cursos organizados por el Council. En caso contrario, deberá llevarse a cabo una Auditoria anual por parte de un QSA. Esto todavía se puede complicar más si resulta que un comercio que por número de transacciones no sea Nivel-2 en MASTER, pero sí lo sea para VISA, automáticamente se considera también Nivel-2 de MASTER.
  37. 37. Este nivel está específicamente diseñado para transacciones de e-commerce y además, no todas las marcas lo consideran. Se entiende como comercio de Nivel-3 a los que procesen el siguiente número de transacciones/año: •Entre 20K y 1 millón de transacciones de comercio electrónico de VISA, MASTER o DISCOVER. •Menos de 50K transacciones AMEX
  38. 38. Se trata del nivel menos restrictivo de todos. La única obligación en estos casos es rellenar el SAQ y se recomienda el realizar un escaneo trimestral de red, aunque se deja a consideración de la entidad adquirente el obligar o no a los comercios a llevarlo a cabo. Evidentemente, esto implica que ninguna entidad lo haga.
  39. 39. Los SP son organizaciones que prestan servicios a los comercios, entidades financieras y/o a otras entidades relacionados con el procesamiento de las transacciones. Los SP incluyen los Procesadores, los Third-Party processors y los Gateway providers, entre otros. En general, cualquier entidad que realice o proporcione servicios relacionados con los medios de pago a terceros. En este apartado también se encuentra Entidades Financieras que realizan determinados servicios: por ejemplo Clearing & Settlement, Autorizaciones en backup, etc a otras entidades financieras.
  40. 40. Se entiende como SP de Nivel-1 a los que procesen el siguiente número de transacciones/año: •Más de 300K transacciones VISA, MASTER. •Cualquier número de transacciones DISCOVER, AMEX o JCB Implica la realización de una Auditoria anual por parte de un QSA generando el ROC (Report Of Compliance) que se envía a cada una de las marcas con las que opera y a la realización de escaneos de red trimestrales por parte de un ASV.
  41. 41. Se entiende como SP de Nivel-2 a los que procesen el siguiente número de transacciones/año: •Menos de 300K transacciones VISA, MASTER. En este nivel sólo es necesario rellenar el ROC y realizar escaneos de red trimestrales por parte de un ASV.
  42. 42. En primer lugar, todas las Entidades (Adquirentes o Emisoras) están obligadas a cumplir PCI-DSS. Las marcas no obligan a las entidades a pasar auditorias anuales. La única marca que realiza tal consideración es DISCOVER, que califica a las Entidades Adquirentes como ‘Proveedores de Servicio’ (SP). También existe una mención por parte de VISA USA en la que se indica que todos los Emisores miembros de VISA que estén conectados directamente a VISANET o que procesen en nombre de otro miembro de VISA deben validar de forma anual su cumplimiento con PCI-DSS, lo cual implica una Auditoria.
  43. 43. Todas las empresas que comercialicen soluciones de software para pagos con tarjetas deben cumplir PA DSS Se certifica una versión específica de software. Las marcas de tarjetas definen el requisito a los clientes de utilizar aplicaciones certificadas. Entre las aplicaciones que aparecen en el listado oficial de aplicaciones certificadas, se encuentran: •E-Payment Integrator •FDMS Integrator •Paymentech Integrator •TSYS Integrator •SmartHUB Kiosk •911 Software CreditLine Secure •Ability OMS •MARKET2
  44. 44. •Promover la integridad del comercio y aumentar la confianza de los consumidores en el negocio. •Incrementar las ventas como consecuencia del aumento en la confianza de los consumidores. •Proteger al comercio de posibles pérdidas de ingresos, investigaciones no deseadas y costos legales. •Reducir el riesgo de atención no deseada de la prensa como resultado de un compromiso o fuga de información de clientes. •Proyectar mayor conciencia de los controles y medidas preventivas de seguridad disponibles para el comercio. •Reducir las disputas de Tarjetahabientes y costos asociados a transacciones fraudulentas resultantes de un compromiso de información. •Prevenir el robo masivo de información de clientes. •Facilitar la adopción de estándares de seguridad válidos a nivel global. •Generar una herramienta que establece las posibles vulnerabilidades que tiene el sistema de información.
  45. 45. Mayo 29, 2013 Solineth Batista - Carlos Pretelt Luigi Ruiz - Ezequiel Vergara ¡GRACIAS!

×