Analytics

lunes, 22 de diciembre de 2014

Breve análisis del documento “PCI Terminal Software Security Best Practices” (TSSBP) del PCI SSC

Los cibercriminales siempre están en búsqueda de nuevas vulnerabilidades para obtener datos de tarjetas de pago de forma fraudulenta. Una de las modalidades que recientemente ha tenido mayor repercusión debido a la gran cantidad de datos robados es el ataque a las terminales de punto de venta (TPV, en inglés Point-of-Sale (POS)), nombre genérico que recibe el hardware y/o software utilizado por los comercios para la captura y procesamiento de datos de tarjeta, por lo general asociado a transacciones presenciales (aquellas en las cuales se emplea el plástico de la tarjeta y el PIN para autenticar la transacción). En estas terminales es muy común la captura de los datos completos de la banda magnética y/o chip EMV y el PIN, por lo que la manipulación/interceptación de los mecanismos operativos del dispositivo o del software instalado con el objetivo de capturar y exfiltrar de forma maliciosa los datos de las tarjetas leídas es un objetivo bastante tentador para un atacante. Bajo este escenario y teniendo presente la gran distribución de terminales de punto de venta en comercios, grandes superficies, centros comerciales y tiendas por departamentos, la forma más sencilla para amplificar y automatizar este ataque es mediante la creación de malware específico para TPV, dependiendo de la plataforma operativa sobre la que se ejecute (Microsoft Windows (sobre todo Windows XP y Windows XP Embedded Edition, que ya no tienen soporte del fabricante), Linux y firmware propietario, entre otros) y/o atacando vulnerabilidades sobre el aplicativo que se ejecute en el TPV.

Desde 2005 se tiene referencia de este tipo de ataques, pero no es sino hasta 2008 cuando VISA toma cartas en el asunto y publica la alerta “Debugging Software – Memory Parsing Vulnerability” (http://usa.visa.com/download/merchants/debugging_software_memory.pdf) en la que describe los hallazgos realizados posterior a una serie de intervenciones forenses en las que habían encontrado componentes de software malicioso diseñado específicamente para extraer datos de tarjetas de pago de sistemas TPV (POS) directamente desde la memoria RAM. Este tipo de malware se conoce con el nombre de RAM Scrapper.  Sin embargo, no es hasta 2012 cuando este tipo de ataques se empiezan a masificar y a tener impacto mediático con los ataques a Target, Home Depot y UPS con el malware BlackPOS, FrameworkPOS y Backoff respectivamente. Actualmente (2014) se encuentran múltiples variantes de este malware “in the wild” (http://www.wildlist.org/), convirtiéndose en una de las principales amenazas para 2015.

Con el fin de proteger los datos de tarjetas de pago cuando se almacenan, se procesan y/o se transmiten, el PCI SSC (Payment Card Industry Security Standards Council) publicó el estándar PCI DSS (Payment Card Industry Data Security Standard). No obstante, dicho estándar está más focalizado en la infraestructura de TI de las empresas que en la gestión de seguridad de dispositivos de extremo en el proceso (como los TPV/POS), por lo cual aún persistía una brecha que había que controlar. Conscientes de ello, el PCI SSC ha publicado este mes el documento “PCI Terminal Software Security Best Practices” (TSSBP) (https://www.pcisecuritystandards.org/documents/terminal_security_best_practices.pdf). Este documento enumera una serie de recomendaciones y buenas prácticas para la protección de datos de tarjetas de pago  y es el resultado de varios meses de esfuerzo de los Grupos de Trabajo (Task Forces) del PCI SSC.

El documento “PCI Terminal Software Security Best Practices” (TSSBP) cubre todos aquellos elementos que no son tenidos en cuenta en estándares como PCI DSS (Payment Card Industry Data Security Standard), PA DSS (Payment Application Data Security Standard) y PCI PTS (PCI PIN Transaction Security), focalizándose, entre otros en los siguientes componentes:
  • Aplicaciones de pago
  • Núcleos (kernel) de EMV
  • Librerías / API
  • Software de terceros
Estas recomendaciones están esquematizadas en cuatro grupos principales:
  • Formación en Concienciación en seguridad (Security-Awareness Training): Cuyo objetivo está focalizado en la creación de un grupo altamente cualificado y con conocimiento suficiente de la plataforma a través de un programa de formación continuo y auditable (4 controles)
  • Establecimiento de un Ciclo de Vida de Desarrollo de Software Seguro (Secure Software-Development Life Cycle (SSDLC)) y definición de roles en los Procesos de Desarrollo Seguro de Software Seguro (Secure Software-Development Process): Como resultado de la definición de un equipo de desarrollo y con el conocimiento de las potenciales amenazas y contramedidas a aplicar, el paso siguiente es el establecimiento de un ciclo de vida de desarrollo de software que incorpore la seguridad desde la base (SSDLC), así como una metodología y documentación que permita darle continuidad al proceso a lo largo del tiempo (12 controles).
  • Pruebas a nivel de dispositivo (Device-Level Testing): El paso siguiente consiste en las pruebas de integración y funcionalidad del software con el dispositivo POI (Point-of-Interaction). Estos dispositivos (al igual que su firmware) deben cumplir con los requerimientos del programa PCI PTS POI y estar listados en https://www.pcisecuritystandards.org/approved_companies_providers/approved_pin_transaction_security.php (4 controles). 
  • Revisiones de procesos internos (Internal Process Reviews): Como complemento a las revisiones a bajo nivel realizadas en los grupos anteriores, se recomienda un análisis de los procesos a alto nivel de la organización, dentro de los que se encuentran el establecimiento de un personal específico encargado de las revisiones y la publicación, la monitorización de alertas de seguridad por parte de terceros, la actualización de las guías de codificación segura y la firma de ficheros (7 controles).
Obviamente este documento no pretende ser la “bala de plata” pero si convertirse en la base de una serie de actividades preventivas con miras a optimizar la seguridad en estos dispositivos. Al ser recomendaciones, no son de obligatoria implementación dentro de la organización (como sí lo son los estándares), pero para aquellas empresas afectadas lo ideal es que integren estas buenas prácticas dentro de sus prácticas habituales o Business-as-usual (BAU) como estrategia global para la minimización de incidentes provenientes de ataques a TPV/POS. Como siempre, es mejor actuar ahora y evitar problemas como los sucedidos con Target y sus 110 millones de datos de tarjetas de pago comprometidos (https://corporate.target.com/about/shopping-experience/payment-card-issue-FAQ).

Desde Internet Security Auditors podemos ayudar a las empresas que quieran afrontar proyectos de revisión de su cumplimiento con esta nueva guía en las áreas de Formación para el personal afectado en las actividades de concienciación en seguridad; en todo lo relativo a la creación de Marcos de Seguridad en Desarrollo de Software siguiendo metodologías reconocidas a nivel internacional; llevando a cabo revisiones técnicas de seguridad y del propio cumplimiento de los requerimientos de las diferentes normas de la "familia PCI" con el objetivo último de la integración de las medidas de seguridad necesarias en los propios procesos de la empresa, tal y como recomienda el PCI SSC.


Autor: David Eduardo Acosta - CISSP, CISA, CISM, CRISC, PCI QSA, CCNA Security, OPST, CHFI Trainer, BS25999 L.A. 
Departamento de Consultoría.