PCI DSS 3.0 HA LLEGADO!!

PCI DSS 3.0 HA LLEGADO!! Evolución continua en la Seguridad de Medios de Pago 14 de Noviembre 2013 Germán Franco, PCI QSA R. Fabian Garzón, CISM, CISSP, + Agenda CERT/CC SEI (Software Engineering Institute) y su relación con PCI DSS Definiciones Previas, ingresando al mundo PCI DSS Cambios destacables en PCI DSS 3.0 Conclusiones Preguntas 1

ACLARACIÓN DE TÉRMINOS Safety Assurance Security Resilience Computer Security (Seguridad Informática) IT Security (Seguridad Informática ó Seguridad en TI) Information Security (Seguridad de la Información) Information Assurance (Seguridad de la Información ó Aseguramiento de la Información) Resilience y Survivality Network Security Internet Security Application Security CIBERSEGURIDAD (CYBERSAFETY vs CYBERSECURITY) SEGURIDAD DE LA INFORMACIÓN Y OTROS DOMINIOS INTERNET Cybercrime Information Security Application Security Cybersecurity CyberSafety CIBERESPACIO Network Security Internet Security CIIP (Critical Information Infrastructure Protection) 2

CERT/CC SEI (Software Engineering Institute) y su relación con PCI DSS Requerimiento 6.5 CERT Secure Coding http://www.cert.org/secure-coding/ Requerimiento 6.2 -> 6.1 El proceso para identificar nuevas vulnerabilidades de seguridad, incluyendo el uso de fuentes externas confiables para obtener información actualizada de vulnerabilidades. Ranking de Vulnerabilidades (CVSS) CERT/CC SEI (Software Engineering Institute) y su relación con PCI DSS 3

Requerimiento 12.9 -> 12.10 CERT/CC SEI (Software Engineering Institute) y su relación con PCI DSS El Plan de Respuesta a Incidentes debe ser completo y contener todos los elementos clave que le permitan a su organización responder de manera efectiva en el evento de una brecha que pueda impactar los datos de tarjetahabiente Personal del equipo de respuesta a incidentes, debe estar entrenado y disponible para evitar que los daños se extiendan Desarrollar un proceso para modificar y evolucionar el plan de respuesta a incidentes de acuerdo a lecciones aprendidas y que incorpore desarrollos de la industria NIST 800-61 (rev 1 y rev 2) ISO 27035 SANS Incident Handling Step by Step CERT/CC Centro de Desarrollo e Investigaciones. Propósito: ayudar a mejorar las capacidades en ingeniería de software, desarrollo y/o adquisición del software correcto, libre de defectos, dentro del presupuesto y a tiempo, todo el tiempo Visión: Liderar y promover software y ciberseguridad para resolver los problemas más duros de la nación Acquisition Support Measurement and Analysis Process & Performance Improvement Smart Grid Cyber-Physical Systems Performance & Dependability Risk Management Software Architecture Digital Intelligence and Forensic Pervasive Mobile Computing Security & Survivability Software Product Lines ACQUISITION SECURITY PROCESS MANAGEMENT SOFTWARE DEVELOPMENT RISK System of Systems Ultra-Large Scale Systems SYSTEM DESIGN 4

CERT Program, desde 1988 esta organización (subsidiaria del SEI,) trabaja en proyectos con un enfoque proactivo para la seguridad de los sistemas y cuyo propósito ha sido mejorar la capacidad y resiliencia de las redes y sistemas de cómputo. CERT/CC Secure Coding CERT/CC PROGRAM Software Assurance Malicious Code Analysis Vulnerability Analysis Forense Coordinated Response CSIRTs development National CSIRTs Secure Systems NetSA CyberSecurity Engineering Governance Training Organizational Security RMM Insider Threat Center SEI PARTNER 5

QUE SIGNIFICA SER SEI CERT/CC PARTNER? Somos una extensión del SEI (Software Engineering Institute) Licenciados para entregar servicios auténticos y con la misma calidad del SEI a través de personal entrenado directamente por SEI Permiso para usar la propiedad intelectual de SEI Acceso al estado del arte en Respuesta a Incidentes Entrenadores en Creación y Gestión de CSIRTs, y en Respuesta Avanzada de Incidentes MODELO DE LA GESTION DE INCIDENTES Preparación Estableciendo la capacidad y el proceso de manejo de incidentes Entrenamiento Guías, instructivos, formatos Listas de notificación Matrices Herramientas de manejo de incidentes Sistemas de seguimiento Manejo de Medios Políticas y procedimientos de respuesta Detección Reportes de los interesados Listas de email privadas o públicas Monitoreo de redes y sistemas IPS /IDS Logs Triage Categorizar Correlacionar Priorizar Asignar Escalar Respuesta (técnica, legal, administrativa) Verificar Contener Investigar Erradicar y mitigar Recuperar Seguimiento Protección Defensas internas y externas actualizadas basados en amenazas nuevas Gestión de parches, cambios y configuraciones Evaluaciones de infraestructura Análisis de riesgos Scans de vulnerabilidades 6

SERVICIOS PROFESIONALES EN RESPUESTA A INCIDENTES DE SEGURIDAD Diagnóstico de sus capacidades de gestión de incidentes (AS-IS state) Asesorías en planeación, implementación, operación y mejora en sus capacidades de respuesta a incidentes de seguridad Servicios para apoyarlo a desarrollar, establecer, operar, mantener y mejorar un equipo de respuesta a incidentes de seguridad(csirt) Entrenamiento avanzado Brecha Compromiso Carders CHD PCI SSC PCI DSS PA DSS QSA ASV BIN CDE PIN PAN CVV CVV2 Truncar Banco Emisor Tokenizar El Mundo PCI Enmascarar ISO 7813 P2PE TRACK HSM Autorización Conciliación CVSS Formula de Luhn ó Modulo 10 ISO 8583 EPP Adquirente Compensación FIM WAF OWASP WIPS Control Compensatorio Inspección de Código PFI PTS PED POS CWE/SANS ATM TDE Proveedores de Servicio PCIP ISA POI 7

LA INDUSTRIA EL PCI SSC Entidades Financieras Asesores Comercios Fabricantes Gateways Redes ACH Proveedores de Servicios Procesadores 8

LATINOAMERICA EN EL PCI SSC NORMAS PCI 9

Qué tienen en común? PCI DSS Payment Card Industry Data Security Standard Norma de seguridad que deben cumplir las organizaciones que Procesan, Transportan o Almacenan datos de cuenta (Account Data). La mejor línea de Defensa contra la Exposición y compromiso a los datos de cuenta. 10

DATOS DE CUENTA = CHD + SAD EL CICLO DE VIDA PCI DSS PCI DSS ver 1.0 del 2005, es la evolución del más maduro estándar de VISA. PCI DSS ver 1.1 válido a partir de Septiembre del 2006 PCI DSS ver 1.2 válido a partir de Octubre 2008 PCI DSS ver 2.0 Divulgada el 28 de Octubre de 2010, válida a partir de Enero 2011 PCI DSS ver 3.0 Divulgada el 7 de Noviembre de 2013, válida a partir de 1 de Enero 2014 11

Feedbacks Más de 200 Feedbacks Queries directos a bases de datos Pen testing por empresas avaladas por el PCI SSC, tipo ASV Scan de vulnerabilidades interno por una ASV Guía sobre scoping y segmentación Más prescriptivo sobre los service providers en acuerdos contractuales y cumplimiento Llaves de encripción vinculadas a cuentas de usuarios, una guía adicional Passwords más exigentes, expandir la autenticación más allá de passwords Requerimiento 12 se vuelva Requerimiento 1 Las revisiones diarias de logs son irreales sin un sistema de alertas establecido y funcional SAD no pueden ser almacenados después de la autorización, pero cuanto tiempo es demasiado tiempo? SAD sin PANS Dejar usar el Logo del PCI SSC DLP(IPS) La Seguridad y el Negocio Funcionalidad (Características) Seguridad (Restricciones) Usabilidad (GUI) 12

Premisas La versión 3.0 introduce más cambios que la versión 2.0. Los 12 requerimientos principales permanecen, hay nuevos subrequerimientos El estándar actualizado pretende ayudar a las organizaciones no haciendo requerimientos más prescriptivos, sino agregando más flexibilidad y guía para integrar la seguridad de los datos de cuenta dentro de las actividades cotidianas de negocio (business-as-usual) Los cambios están diseñados para darle a las organizaciones una fuerte pero flexible arquitectura de seguridad basada en principios Tipos de Cambios CLARIFICACIONES Se clarifica el propósito del requerimiento. Palabras precisas y concisas en la norma que muestren el propósito deseado del requerimiento. 74 GUIA ADICIONAL Explicaciones y/o definiciones adicionales para aumentar el entendimiento o brindar información adicional sobre un tópico particular 5 REQUERIMIENTO MEJORADO EVOLUCIÓN Cambios para asegurar que la norma se mantiene actualizada con amenazas emergentes y cambios en el mercado 19 13

La Estructura de la Norma La Estructura de la Norma Procedimientos de prueba mejorados para clarificar el nivel de validación esperado para cada requerimiento 14

Procedimientos de prueba mejorados (muestra) Procedimientos de prueba mejorados (muestra) 15

La Estructura de la Norma La plantilla para elaborar el PCI DSS ROC se emite en el primer trimestre del 2014 ROC REPORTING TEMPLATE Fuente: https://www.pcisecuritystandards.org/documents/pci_dss_2.0_roc_reporting_instructions.pdf 16

Educación y Concientización Temas clave Flexibilidad Mejores prácticas Business-as-usual Navigating PCI DSS se incorpora Educación a usuarios en cuanto a Passwords (8.4) Entrenamiento a los PA-DSS vendors Políticas de seguridad y procedimientos operacionales integrados en cada Requerimiento Entrenamiento y seguridad en POS security (9.9) La Seguridad como una responsabilidad compartida Seguridad en terminales POS Password de los proveedores de servicio Definir las Responsabilidades de los Proveedores y Clientes Balance entre lo prescriptivo y la flexibilidad mientras no se debilite la integridad, la fortaleza o efectividad del estándar, y sin restringir a las organizaciones a que utilicen métodos específicos Fortaleza/Complejidad de Passwords Detección de cambios Revisión de logs basado en riesgos WAF o mecanismo similar Respuesta a Nuevas Amenazas Cambios de passwords default aplica a cuentas de servicio, cuentas de aplicaciones y cuentas de usuarios Vulnerabilidades en código para ser evitadas en los procesos de desarrollo de software Aclaraciones iniciales (A) SAD (Datos Sensibles de Autenticación) no deben ser almacenados después de la autorización, incluso si están cifrados. Esto aplica incluso donde no hay PAN en el entorno. Las organizaciones deben contactar directamente a su adquirente o a las marcas para entender si SAD es permitido ser almacenado antes de la autorización, por cuanto tiempo, y cualquier requisito de uso y protección. 17

Aclaraciones iniciales (B) CDE Componentes de Sistema incluyen dispositivos de red, servidores, dispositivos de cómputo y aplicaciones. Componentes de sistema incluyen pero no están limitados a los siguientes: Sistemas que proveen servicios de seguridad (por ejemplo, servidores de autenticación), que facilitan la segmentación (por ejemplo, firewalls internos), o pueden impactar la seguridad del CDE. Componentes de Virtualización tales como máquinas virtuales, switches/routers virtuales, appliances virtuales e hypervisors. Aclaraciones iniciales (B) CDE Componentes de red incluyendo pero no limitados afirewalls, switches, routers, wireless access points, network appliances, y otros security appliances. Tipos de Servidores, incluyendo pero no limitados a web, aplicación, base de datos, autenticación, mail, proxy, NTP, and DNS. Aplicaciones incluyendo las compradas y personalizadas, incluyendo internas y externas Cualquier otro componente o dispositivos ubicado dentro o conectado al CDE 18

Sección nueva Mejores prácticas para la Implementación de PCI DSS dentro de los procesos de negocio normales/cotidianos Best Practices for Implementing PCI DSS into Business-as-Usual Processes Monitoreo de los controles de seguridad Si un control falla: Restauración, Identificar la causa de la falla, resolver los asuntos de seguridad que surgieron durante la falla, evitar que falla del control vuelva a ocurrir, monitoreo mejorado por un periodo de tiempo para verificar la restauración efectiva del control Cambios en el entorno PCI DSS como parte de la estrategia de seguridad corporativa Comunicaciones y revisiones periódicas Revisiones anuales de hardware y software (soporte) Políticas y procedimientos operacionales Documentados, en uso y conocidos 12.1.1 La política de seguridad debe abordar todos los requerimientos de PCI DSS 12.2 Desarrollar procedimientos de seguridad operacionales diarios que sean consistentes con los requerimientos (por ejemplo, procedimientos de mantenimiento de cuentas de usuarios, procedimientos de revisión de logs) 1.5 Asegurese que las políticas de seguridad y procedimientos operacionales para gestionar firewalls estén documentados, en uso y sean conocidos por todas las partes afectadas 2.5 Asegurese que las políticas de seguridad y procedimientos operacionales para gestionar parámetros de seguridad y otros valores por defecto de los fabricantes estén documentados, en uso y sean conocidos por todas las partes afectadas 3.7 Asegurese que las políticas de seguridad y procedimientos operacionales para proteger datos de tarjetahabiente almacenados estén documentados, en uso y sean conocidos por todas las partes afectadas 19

Políticas y procedimientos operacionales Documentados, en uso y conocidos 4.3 Asegurese que las políticas de seguridad y procedimientos operacionales para cifrar las transmisiones de datos de tarjetahabiente estén documentados, en uso y sean conocidos por todas las partes afectadas 6.7 Asegurese que las políticas de seguridad y procedimientos operacionales para desarrollar y mantener sistemas seguros y aplicaciones estén documentados, en uso y sean conocidos por todas las partes afectadas 5.4 Asegurese que las políticas de seguridad y procedimientos operacionales para proteger sistemas contra malware estén documentados, en uso y sean conocidos por todas las partes afectadas Políticas y procedimientos operacionales Documentados, en uso y conocidos 7.3 Asegurese que las políticas de seguridad y procedimientos operacionales para restringir acceso a datos de tarjetahabiente estén documentados, en uso y sean conocidos por todas las partes afectadas 8.8 Asegurese que las políticas de seguridad y procedimientos operacionales para la identificación y autenticación estén documentados, en uso y sean conocidos por todas las partes afectadas 9.10 Asegurese que las políticas de seguridad y procedimientos operacionales para la restricción de acceso físico a los datos de tarjetahabiente estén documentados, en uso y sean conocidos por todas las partes afectadas 20

Políticas y procedimientos operacionales Documentados, en uso y conocidos 10.8 Asegurese que las políticas de seguridad y procedimientos operacionales para monitorear todos los accesos a recursos de red y datos de tarjetahabiente estén documentados, en uso y sean conocidos por todas las partes afectadas 11.6 Asegurese que las políticas de seguridad y procedimientos operacionales para el monitoreo y las pruebas de seguridad estén documentados, en uso y sean conocidos por todas las partes afectadas Novedades: Requerimiento 1 1.1.2 Diagrama de red actualizado con todas las conexiones a datos de tarjetahabiente, incluyendo cualquier red inalámbrica 1.1.2.a Verificar que el diagrama de red actual (por ejemplo, uno que muestre los flujos de datos de tarjetahabiente en la red) existe y que documenta todas las conexiones a datos de tarjetahabiente 1.1.3 Diagrama de red actualizado que muestra todos los flujos de datos de tarjetahabiente a través de sistemas y redes Mostrar todos los flujos de datos de tarjetahabiente a través de sistemas y redes 1.1.6 SNMP v1 and v2 inseguros 1.2.2 Archivos de configuración de routers asegurados de accesos no autorizados 1.3.4 Implementar medidas anti-spoofing para detectar y bloquear IPs fuentes falsificadas 21

Novedades: Requerimiento 2 Guías de Hardening 2.1 Siempre cambie los valores default entregados por los fabricantes y remueva o deshablite cuentas default innecesarias antes de instalar un sistema en la red. Esto aplica a TODOS los passwords default, incluyendo pero no limitados a aquellos usados en Sistemas operativos, software que provee servicios de seguridad, aplicaciones y cuentas de sistema, terminales POS, cadenas SNMP, etc 2.2.d Verificar que los estándares de configuración incluyen los siguientes procedimientos para todos los tipos de componentes de sistema: Cambio de todos los valores default suministrados por los fabricantes y eliminación de cuentas default innecesarias Implementación de solo una función principal por servidor Habilitar solo servicios necesarios, protocolos, etc Remover todas las funcionalidades innecesarias, tales como scripts, drivers, propiedades, subsistemss, file systems, y servidores web innecesarios 2.4 Mantener un inventario de componentes de sistema que están en el alcance de PCI DSS Novedades: Requerimiento 3 3.2 No almacene datos sensibles de autenticación después de la autorización (incluso si están cifrados) Si datos sensibles de autenticación son recibidos, deje todos estos datos irrecuperables (unrecoverable) hasta que se complete el proceso de autorización 3.2.c. Si datos sensibles de autenticación son recibidos, revisar las políticas y procedimientos, y examinar las configuraciones de los sistemas para verificar que los datos no son retenidos después de la autorización 3.3.a Examinar las políticas y procedimientos para enmascarar el despliegue de PANs para verificar: Una lista de roles que necesitan acceso a despliegues de full PANs está documentada, junto con una necesidad legítima de negocio para cada rol que tiene dicho acceso. 22

Novedades: Requerimiento 4 Ejemplos de redes públicas abiertas incluyen pero no están limitadas a Internet Tecnologías Wireless (802.11 y Bluetooth ) Tecnologías de Cellular, por ejemplo Global System for Mobile communications (GSM), Code division multiple access (CDMA) General Packet Radio Service (GPRS). Comunicaciones satelitales Novedades: Requerimiento 5 Requerimiento 5: Utilice y regularmente actualice el software o los programas anti-virus Requerimiento 5: Proteja todos los sistemas contra malware y regularmente actualice el software o los programas anti-virus 5.1.2 Para aquellos sistemas que se consideran no ser generalmente afectados por software malicioso, desempeñe evaluaciones periódicas para identificar y evaluar amenazas de malware evolucionadas, para confirmar si dichos sistemas continuan ó no requiriendo software anti-virus 5.3 Asegurarse que los mecanismos de anti-virus estén activos continuamente y no pueden ser deshabilitados ó alterados por los usuarios 23

Novedades: Requerimiento 6 Cambió el órden: 6.1 y 6.2. 6.3. Nota: esto aplica a todo el software desarrollado internamente así como software desarrollado por un tercero (bespoke or custom software) 6.5.b Entrevistar una muestra de personal de desarrollo y obtener evidencia de que ellos conocen técnicas de codificación segura 6.5.c Registros de entrenamiento para verificar que los desarrolladores de software recibieron entrenamiento en técnicas de codificación segura, incluyendo como evitar vulnerabilidades de seguridad comunes y entiendan como los datos sensibles son manejados en memoria 6.5.6 Coding techniques document how PAN/SAD is handled in memory, to minimize potential exposure. Novedades: Requerimiento 6 6.5.10 Broken authentication and session management 6.6 Para public-facing web applications Flagging session tokens (por ejemplo cookies) as secure No exponer session IDs en el URL Incorporar time-outs adecuados y rotación de session IDs después de login exitosos Métodos: Métodos manuales o automáticos de valoración de vulnerabilidades a aplicaciones Nota: Diferente al 11.2. Instalar una solución técnica que detecte y evite ataques basados en web (por ejemplo, un web-application firewall) 24

Novedades: Requerimiento 7 Clarificaciones respecto al manejo de roles y las necesidades de acceso Novedades: Requerimiento 8 Requerimiento 8: Asignar un Único ID a cada persona con acceso a computadores Requerimiento 8: Identificar y autenticar accesos a los componentes de sistema 8.3 Combinó la complejidad mínima para passwords y fortaleza en un único requerimiento, e incrementó la flexibilidad respecto a alternativas que sean equivalentes a la complejidad y fortaleza: Longitud mínima 7 caracteres Contener caracteres numéricos y alfabéticos De manera alterna, los passwords/phrases deben tener complejidad y fortaleza, al menos equivalente a los parámetros arriba especificados 25

Novedades: Requerimiento 8 8.5.7 Comunicar las políticas y procedimientos de autenticación a todos los usuarios que tienen acceso a CHD 8.4 Documentar y comunicar las políticas y procedimientos de autenticación a todos los usuarios incluyendo: Guía sobre seleccionar credenciales de autenticación fuertes Guía sobre como los usuarios deben proteger sus credenciales de autenticación Instrucciones para no reutilizar passwords previamente usados Instrucciones para cambiar passwords si hay sospechas que el password pudo ser comprometido Novedades: Requerimiento 8 8.5.1 Requerimiento adicional para proveedores de servicio: Proveedores de Servicio con acceso remoto a instalaciones del cliente (por ejemplo, para soporte a sistemas POS o servidores) deben usar una única credencial de autenticación (tal como password/phrase) para cada cliente 26

Novedades: Requerimiento 9 9.3 Control de Acceso Físico para personal en sitio a las áreas sensibles, de esta manera: Acceso debe ser autorizado y basado en la función del individuo Acceso es revocado inmediatamente al terminar el empleo, y todas las llaves, tarjetas de acceso y mecanismos de acceso físico deben ser regresados o deshabilitados Novedades: Requerimiento 9 9.9 Proteger dispositivos que capturan CHD vía interacción directa con la tarjeta, de alteración y sustitución 9.9 Examinar políticas y procedimientos documentados para verificar que estos incluyan: Mantenimiento de una lista de dispositivos Inspeccionar periodicamente dispositivos para buscar manipulacions o sustituciones Entrenar al personal para que sepan identificar comportamientos sospechosos y para reportar las alteraciones o sustituciones de los dispositivos 27

Suplemento Novedades: Requerimiento 10 10.2.5 Uso de mecanismos de identifcación y autenticación 10.2.5 Uso de y cambios a los mecanismos de identificación y autenticación incluyendo pero no limitado a la creación de nuevas cuentas o elevación de privilegios- y todos los cambios, adiciones o borrados de cuentas con privilegios administrativos o tipo root 28

Novedades: Requerimiento 10 10.2.6 Inicialización de los logs de auditoría 10.2.6 Inicialización, apagado o pausa de los logs de auditoría 10.6.1 Revisión de logs al menos diariamente: Todos los eventos de seguridad Logs de todos los componentes de sistema que almacenan, procesan o transmiten CHD y/o SAD, o que pueden impactar la seguridad del CHD y/o SAD Logs de todos los componentes de sistema críticos Logs de todos los servidores y componentes de sistema que desempeñan funciones de seguridad 10.6.2 Revisión de logs periódica de otros componentes de sistema basado en las políticas y estrategia de gestión de riesgos, como se determinó en la valoración anual de riesgos Novedades: Requerimiento 11 11.1.1 Mantener un inventario de los access points inalámbricos autorizados incluyendo la justificación de negocio documentada 11.2 Nota: Múltiples reportes de escans pueden ser combinados que muestren que todos los sistemas fueron escneados y que las vulnerabilidades aplicables fueron resueltas. Documentación adicional pude ser requerida para verificar las vulnerabilidades no remediadas y que están en proceso de ser remediadas 29

Novedades: Requerimiento 11 11.3 Implementar una metodología para pruebas de penetración (intrusión) que incluya lo siguiente: Basada en enfoques de industria (por ejemplo, NIST SP800-115) Incluya pruebas tanto desde adentro como afuera de la red Incluya pruebas para validar cualquier segmentación y controles de reducción de alcance 11.3.4 Verificación de la segmentación y aislamiento de sistemas fuera del alcance Defina las pruebas de penetración a la capa de aplicación, como mínimo las vulnerabilidades del requerimiento 6.5 Novedades: Requerimiento 11 11.5 Despliegue de mecanismos de detección de cambios (por ejemplo herramientas FIM) para alertar al personal de modificaciones no autorizadas de archivos de sistema críticos,..; y configurar el software para ejecutar la comparación al menos semanalmanete 11.5.1 Implementar un proceso para responder a cualquier alerta generada por la solución de detección de cambios 30

Novedades: Requerimiento 12 12.8.5 Mantener información sobre cuales requerimientos PCI DSS son gestionados por cada proveedor de servicio, y cuales son gestionados por la entidad 12.9 Requerimiento adicional para los proveedores de servicio: Los proveedores de servicio reconocen por escrito a sus clientes, que ellos son responsables por la seguridad de los datos de tarjetahabiente que el proveedor posee, o almacena, procesa o transmite en nombre del cliente, o al grado en que ellos puedan impactar la seguridad del CDE del cliente Aclaración: Requerimiento 12 12.3.10 Any such authorized personnel are responsible for ensuring that cardholder data in their possession is handled in accordance with all PCI DSS requirements, as that remote personnel s environment is now considered a part of the organization s cardholder data environment. 31

Grupos de interés especial (SIG) 2012 Grupos de interés especial (SIG) 2014 Best Practices for Implementing a Formal Security Awareness Program Best Practices for Merchants: Skimming Prevention Best Practices for Small Merchants 2013 Encryption Key Management Guidance Guidance on Securing Admin Access to CDE Guidance on Steps to Obtain PCI DSS Certification Third Party Security Assurance Incident Response Plan Toolkit Best Practices for Maintaining PCI DSS Compliance Increase Security at Retail Stores PCI DSS as it relates to "Mainframe Type" Environments Penetration Testing Scoping Guidance 32

Making payment security business-as-usual Best Practices for Maintaining PCI DSS Compliance Qué PCI DSS sea un programa que facilite y soporte la seguridad de manera constante y a largo plazo de los datos de tarjetahabiente de la organización Disminuir el conflicto que surge cuando las prioridades del negocio inhiben el cumplimiento continuo de PCI después del cumplimiento inicial alcanzado Combinar PCI DSS con objetivos de negocio y formular los controles de gobierno apropiados, en ambientes de constante cambio Best Practices for Maintaining PCI DSS Compliance Explorar varias estructuras de gobierno (COSO, 27001, 27002, COBIT, ITIL) y desarrollar una guía que incluya: Integración PCI DSS en el negocio y los procesos de cambio Mejores prácticas y controles que ayuden la cumplimiento constante y como parte de BAU 33

LA SOBRECARGA DEL CUMPLIMIENTO Regulación Internacional SOX SARO Circu lares Regulación Nacional Leyes de Proteccion de Datos Regulación de Industria SARC, SARLAFT PCI DSS Intromisión Externa No Deseada? COBIT, ISO 27002, ISO 27001 ITIL PROYECTOS PMI ORGANIZACION GRC GESTION DE RIESGOS y CUMPLIMIENTO CONSIDERACIONES FINALES Determine con Precisión el Alcance y actualice flujos de CHD El Cumplimiento es resultado de la Seguridad (Integración con un SGSI) Aunque haya tiempo, adopte PCI 3.0 lo más pronto posible Aproveche los recursos del PCI Security Standards Council https://www.pcisecuritystandards.org/index.shtml Un Estándar de Seguridad lo suficientemente maduro, que ha ayudado en la reducción de fugas y fraudes 34

Germán Franco, PCI QSA german.franco@iqcol.com R. Fabian Garzón, CISM, + fabian.garzon@iqcol.com Gracias Calle 109 No. 18 B-31, Of. 205 Tel: (57 1) 619 6392 / 81 Fax: (57 1) 703 3216 Bogotá, Colombia www.iqcol.com 35