Analytics

jueves, 27 de marzo de 2014

Compromiso de datos de pago en el organismo público de tráfico de California

Según se hizo eco la semana pasada Brian Krebs en su blog, el organismo público regulador de vehículos del estado norteamericano de California, DMV (Department of Motor Vehicles) responsable de las matriculaciones, emisión de carnés para conductores, registro de vehículos, licencias para profesionales del sector del transporte, concesionarios, etc. y que gestiona 33 millones de vehículos matriculados y 23 millones de conductores con licencias, habría sufrido un compromiso de datos de tarjetas. El compromiso, según la nota de prensa emitida por la propia Mastercard podría potencialmente haber "[...] comprometido transacciones durante el período del 2 de agosto de 2013 al 31 de enero de 2014 y la información robada incluir los número de tarjeta, fechas de espiración y los tres dígitos del código de seguridad."

http://krebsonsecurity.com/2014/03/sources-credit-card-breach-at-california-dmv/

El compromiso, inicialmente parece ser que trascendió por la filtración de las notas de algunos bancos en California para la congelación de tarjetas de pago y el DMV emitió una nota en la que parecía trasladar la responsabilidad a un tercero.

A medida que Krebs ha ido obteniendo información ha publicado lo que podría ser un incidente muy relevante del que no hay todavía información pública. Según las conclusiones de la nota de prensa de DMV y las pesquisas llevadas a cabo por el blogger, el compromiso podría haberse dado en uno de sus proveedores de servicio de procesamiento. Actualmente, DMV parece trabajar con los dos mayores del mundo, First Data y Elavon. Ambos han trasladado directa o indirectamente no ser la causa de la brecha y estar estudiando con el DMV el incidente.

Steve Ragan de la publicación CSO Online también se ha hecho eco investigando diferentes fuentes e intentando aportar algo de luz a este compromiso de datos de tarjeta del que se tiene muy poca información oficial:

http://blogs.csoonline.com/network-security/3094/follow-california-dmv-breach-blamed-elavon

Está claro que no sólo las empresas privadas son el objetivo del fraud business. Allí donde se puedan robar datos de pago, se podrán sufrir incidentes y, esta vez, le ha tocado a la administración pública norteamericana.


martes, 18 de marzo de 2014

Fin del soporte de Windows XP y su impacto en PCI DSS

A partir del 8 de Abril de 2014 Microsoft finalizará el soporte a sistemas operativos Windows XP y a la suite ofimática Office 2003, tal como lo describen en su página “Windows lifecycle fact sheet“. Esto implica que a partir de ese día este software no recibirá más actualizaciones de seguridad ni soporte técnico por parte del fabricante.

¿Qué implicaciones tiene esta noticia en el cumplimiento de PCI DSS?

El requerimiento 6.2 de PCI DSS v3.0 establece lo siguiente:
6.2 Asegúrese de que todo el software y componentes del sistema tengan instalados parches de seguridad proporcionados por los proveedores que ofrecen protección contra vulnerabilidades conocidas. Instale los parches importantes de seguridad dentro de un plazo de un mes de su lanzamiento.
Debido a ello, tener dentro del alcance de cumplimiento un equipo con un sistema operativo sin soporte por parte del fabricante puede implicar un incumplimiento del estándar, aparte de los potenciales problemas derivados de las vulnerabilidades de seguridad no corregidas y la consecuente exposición a riesgos por parte del negocio.

¿Cuál es el impacto de esta noticia en los sistemas de información de entidades que procesan datos de tarjetas de pago?

De acuerdo con Net Applications, en Febrero de 2014 Windows XP ocupaba el segundo lugar con 29,53% en la cuota de uso de sistemas operativos de escritorio, lo cual demuestra claramente su importancia después de 12 años de haber sido publicado por primera vez, a pesar de la gran cantidad de críticas que tuvo durante este tiempo.
Uso de WIndows XP a Febrero de 2014
Fig.1 Uso de Windows XP a Febrero 2014
Por otro lado, según Digital Trends el 95% de los cajeros electrónicos (ATM) existentes en el mundo se ejecutan bajo esta plataforma operativa. Sin soporte técnico por parte del fabricante, sin actualizaciones y con muy pocas soluciones de seguridad que soporten Windows XP, el panorama se visualiza muy complicado, teniendo presente que cada día se identifican nuevas muestras de malware orientado al ataque de cajeros electrónicos.

¿Qué alternativas se tienen para gestionar el riesgo frente a esta plataforma no soportada?

Para aquellas empresas que aún cuentan con plataformas operativas Windows XP en su entorno, a continuación se enumeran las alternativas para gestionar este riesgo:
Migración/actualización a Microsoft Windows 7/8
Esta es la opción recomendada por Microsoft como camino directo frente a la notificación de finalización de soporte de Windows XP.
Ventajas:
  • Relativa facilidad y potencial compatibilidad entre aplicativos
  • El soporte y la recepción de actualizaciones de seguridad continuarán sin cambios si se continúa trabajando con la plataforma operativa del mismo fabricante
  • Microsoft ha puesto a disposición una herramienta gratuita para la migración de perfiles de usuario y archivos desde Windows XP a Windows 7/8 denominada PCmover Express for Windows XP, que puede apoyar el proceso de transición entre plataformas
  • Si los equipos Windows XP se encuentran vinculados a un Directorio Activo, la gestión de políticas de seguridad se pueden migrar de forma sencilla
Desventajas:
  • Obviamente, los requerimientos de hardware para Windows 7 y Windows 8 son superiores a los de Windows XP, lo cual puede convertirse en un problema para ordenadores limitados, como es el caso de cajeros electrónicos y Terminales de Punto de Venta (TPV)
  • Costes de licenciamiento
  • Problemas con integración de componentes de software antiguos
Migración a una nueva plataforma operativa
En este punto coyuntural, plantearse la migración a una nueva plataforma operativa como GNU/Linux o sistemas BSD puede ser contemplada como una opción a corto plazo.
Ventajas
  • Ahorro en costes de licenciamiento (*)
  • Facilidad en personalización y minimización de componentes de software
  • Acceso al código fuente (*)
  • Integración con hardware limitado
  • Minimización en los problemas provenientes de malware
Desventajas
  • Problemas de compatibilidad e integración con aplicativos existentes que se ejecutan sobre plataformas Microsoft Windows
  • Soporte técnico (a menos que se adquiera soporte licenciado)
  • Gestión de actualizaciones
(*) En el caso de sistemas operativos OpenSource

Uso de controles compensatorios
Esta es una alternativa a corto plazo y temporal, debido a que tarde o temprano será necesario migrar a una nueva plataforma, a pesar que haya bastante resistencia a ello. Si se opta por esta opción, el PCI SSC publicó su FAQ 1130 “Are operating systems that are no longer supported by the vendor non-compliant with the PCI DSS?” en donde analiza el potencial uso de controles compensatorios cuando se cuenta con una justificación técnica o administrativa que lo avale. En este caso, es necesario contar con el soporte de un asesor QSA, quien analizará el ámbito específico de la organización y recomendará los controles necesarios.

Es importante tener presente que a pesar que el soporte técnico y actualizaciones del sistema operativo Windows XP serán finalizadas por parte de Microsoft, la herramienta Malicious Software Removal Tool continuará recibiendo actualizaciones hasta Julio 14 de 2015.

Debido a la inminencia en la finalización del soporte de Windows XP, el PCI SSC publicó el infográfico “Windows XP – Support is ending”  donde realiza un análisis general de los problemas y alternativas frente a este anuncio. Igualmente, en la página WindowsXP.com se ofrece más información por parte de Microsoft.


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

lunes, 17 de marzo de 2014

Crónica de la “Corelan Live: Win32 Exploit Development Bootcamp” en RootedCon 2014

Como ya es bien conocido en la comunidad de seguridad, los días 6, 7 y 8 de Marzo tiene lugar uno de los mejores congresos de seguridad informática de ámbito nacional, la RootedCon. Este año, la organización hizo un esfuerzo extra para intentar ofrecer una visión más internacional al evento tanto aceptando propuestas de ponentes extranjeros como ofreciendo servicios de traducción simultánea. Sin embargo, el tema que vamos a tratar en este artículo versa, posiblemente, del mejor training de explotación de software a nivel internacional.

La organización de la RootedCon consiguió que Peter Van Eeckhoutte, aka @corelanc0d3r, viniera por primera vez a España a impartir su “Corelan Live: Win32 Exploit Development Bootcamp”, marcando un precedente, como suele ocurrir con muchas de las cosas que se llevan a cabo en la RootedCon.

El Bootcamp de Corelan tiene una duración de dos días, sin embargo, ya nos avisaron de que no iban a ser dos días muy normales, que tuviéramos claro que se iba a dormir muy poco. Y así fue. El training de Corelan bien se podría hacer durante toda una semana. El primer día de training empezó a las nueve de la mañana, durando hasta la una y media. No, no la una y media del medio día... sino ¡de la madrugada! Un total de 16 horas y media de training, contando la hora para comer. El segundo día empezó sobre las nueve y acabó a las dos y media. 17 horas y media. Y acabamos a las dos y media porque Peter nos vio las caras de incredulidad y desesperación cuando dijo que estaría bien acabar cierto exploit antes de irnos. Un use Use-After-Free haciendo Heap Spraying y ROP, que en condiciones normales posiblemente nos hubiera llevado una o dos horas, pero después de un total de unas 33 horas de training en dos días, todo apuntaba a que nos iba a llevar todo lo que quedaba de noche.

¡Si esto no te ha convencido para hacer el training en cuanto puedas, no sé qué podría hacerlo!
Cuando se presentan los requisitos del training, sorprendentemente se afirma que no son necesarios conocimientos previos de exploiting y hasta se afirma que no es necesario tener conocimientos de ensamblador. Después de asistir al bootcamp, por extraño que parezca, me pareció que realmente sí que era cierto que no eran necesarios conocimientos de ensamblador.

Durante todo el training, Peter tiene preparados todo un conjunto de ejercicios en los que te presenta las aplicaciones vulnerables y un pequeño Proof of Concept que utiliza para generar un crash en la aplicación. A partir de ese momento, eres tú el que se encarga de hacer de ese crash una ejecución de código arbitraria. Esto significa que en ningún momento necesitas hacer reversing de la aplicación para identificar la vulnerabilidad. Evidentemente vas a tener que leer un poco de ensamblador, pero con unos conocimientos básicos que te da el propio Peter ya es más que suficiente.

Por otro lado, creo que lo que no es tan cierto es que no se necesiten conocimientos previos de exploiting. Es verdad que Peter asume que los asistentes no tienen estos conocimientos (hasta te refresca aspectos de arquitectura de computadores de primero de carrera) pero la curva de aprendizaje es exponencial. Juzga tú mismo: ¿crees que es posible no tener ni idea de lo que es un desbordamiento de búfer y al cabo de dos días estar explotando vulnerabilidades en navegadores web a través de Use-After-Free? Peter casi materializa este milagro, pero te aconsejo que antes de asistir al training pongas un poco de tu parte para no perderte a medio camino. Una buena estrategia es hacer un repaso a sus tutoriales. No hace falta que llegues a los últimos, pero sí que deberías asistir al training con unos conceptos sólidos.

En fin, vayamos a lo interesante.

El primer día, nos adentramos en el mundo del exploiting en Windows a través de desbordamientos básicos de bufers para, como diría el propio Peter, influenciar el registro EIP (que no es lo mismo que sobrescribirlo). Después se hace hincapié en técnicas para evadir medidas de seguridad como SEH, repasando conceptos como SafeSEH o SEHOP, pero sin entrar en profundidad en ellos. También se programan varios módulos de Metasploit para facilitar el desarrollo de los exploits. Durante este primer día también se tocan otros conceptos como el uso de los debuggers, la identificación de caracteres inválidos en los payloads o el uso de una de mis nuevas herramientas favoritas, Mona.
Este podría parecer un día básico para alguien con conocimientos sobre exploiting, pero lo cierto es que se obtienen unos conocimientos y metodologías muy robustos que establecen la base para seguir hacia adelante. Eres capaz de vislumbrar el modo de pensar y trabajar de una persona que se ha dedicado al desarrollo de exploits durante más de diez años. Para todos aquellos que tengáis unos conocimientos sólidos sobre métodos de explotación de software, estoy seguro que las siguientes frases de Peter (las digo de memoria, así que puede que su forma literal varíe) os harán plantear ciertas cosas:
- "Si alguien os dice que puede sobrescribir EIP, ¡huid! A EIP sólo se le puede influenciar."
- "Si alguien os dice que puede sobrescribir una vtable, ¡huid!"
Y la que a mí más me gustó y, a la vez, más me chocó es:
- "Si alguien está utilizando NOPS en su exploit, probablemente no tenga ni idea de lo que está haciendo"

Ahora decidme... Alguna vez habéis utilizado NOPS en vuestros exploits? Si es así, es momento de plantearos si realmente era necesario o simplemente no teníais muy claro lo que estaba ocurriendo. :)
El segundo día del training nos adentramos en conceptos algo más avanzados como DEP o ASLR. A diferencia del primer día en el que se trabaja con Windows XP SP3, este segundo día se trabaja sobre Windows 7. Esto nos llevó toda la mañana y parte de la tarde. Llegados a este punto se supone que ya eres capaz de programar módulos de Metasploit sin muchos problemas y utilizarlos para explotar las vulnerabilidades. De la tarde hasta la madrugada se empezó a profundizar en temas como Heap Spraying y Use-After-Free. Por desgracia, no nos dio tiempo de asentar los conocimientos más avanzados tal y como había ocurrido con los conocimientos del primer día. Tampoco pudimos abordar el tema de information leaks.

Esto sería un problema, si no fuera porqué después del training, a los asistentes se les da acceso a un foro+IRC privado para que todas tus dudas sean resueltas por el propio Peter u otros estudiantes. Sí, lo habéis leído bien. Después del training, Peter sigue resolviendo tus dudas. De nuevo, el precio/hora del training parece que se reduce. :)

Comentar que todas las vulnerabilidades que se explotan en el training son reales, pasando por simples reproductores de música hasta Wireshark o navegadores web. Además hay muchos ejercicios que se quedan en el tintero, para que los pienses tu en casa.

Por último, me gustaría recalcar el valor añadido que ofrece Peter.
A nivel personal, es el profesor más implicado que jamás he visto. ¿Sabéis lo que es estar encerrado durante 17 horas en la misma sala y que él siga motivándote? Siempre que nos ponía un ejercicio iba dando vueltas por la sala en vez de quedarse sentado en su sitio esperando a que lo llamaras, con lo que era mucho más amigable plantearle dudas. Cuando avanzaba con los ejercicios, se aseguraba (dentro de lo posible) que todos lo hubiéramos conseguido.

A nivel pedagógico, Peter es muy bueno explicando. A mí, que ya tenía experiencia previa, me quedaron claros la mayoría de los conceptos. Sin embargo, vi a personas que se perdían a medio camino. Lo que es evidente es que, por un lado, sin unos conocimientos sólidos te va a ser más difícil seguir la clase, y por el otro, si te despistas 5 o 10 minutos, te pierdes. Así que debes mantenerte concentrado todo el tiempo.

Por último, a nivel de conocimientos, Peter es excepcional y, además, trabaja duro. Esto se puede apreciar en muchos momentos. Te da explicaciones sobre ciertos conceptos que normalmente no se encuentran por la red (aún menos en libros). Te explica cosas que la gente acostumbra a hacer, sin saber realmente porqué las hace y te explica por qué ya no son necesarias. Te ofrece información que ha descubierto él mismo y que, por lo que se puede apreciar, seguro que obtenerla le ha llevado una buena cantidad de horas. Además, al final del training habrás interiorizado un modo de trabajar y de pensar que puede facilitarte mucho las cosas en el momento de encarar otros escenarios por tu cuenta.
Ahora, como dice Peter, llega el punto clave: si la semana siguiente al training no repasas todos los conceptos explicados es muy posible que todo esto no haya servido de nada. Por suerte, en las diapositivas y los materiales del training hay decenas de ejercicios que no se hicieron en el training, con lo que hay diversión para tiempo. Por suerte, tendremos el apoyo de Peter con todas las dudas que nos puedan surgir.

Y sobre todo, ¡Don't look the next slide!

Autor: Albert López
Departamento de Auditoría

Vicente Aguilera Diaz forma parte del Hall of Fame de Barracuda Networks

Vicente Aguilera Diaz (@VAguileraDiaz) forma parte del Hall of Fame que gestiona Barracuda Networks como parte de su programa Bug Bounty.

Este Hall of Fame reconoce tres niveles distintos de contribuciones en funcion de la criticidad de las vulnerabilidades reportadas:
  • GOLD: reconoce a investigadores que han reportado vulnerabilidades que potencialmente podrían suponer un riesgo significativo para los clientes de Barracuda Networks.
  • SILVER: reconoce a investigadores que han reportado vulnerabilidades que existen en los productos de Barracuda pero que no representan un riesgo significativo para sus clientes.
  • BRONZE: reconoce a investigadores que han reportado otros problemas de seguridad, independientemente de si forman parte o no de las recompensas del programa Bug Bounty.
Vicente ha reportado tres vulnerabilidades de distinta gravedad, afectando a Barracuda Phone System (CudaTel) y Barracuda WAF (Web Application Firewall), lo que le ha permitido ser reconocido en los niveles GOLD y SILVER.

Más información:
  • Barracuda Networks Bug Bounty Hall of Fame:
  • Barracuda Networks Bug Bounty program:

viernes, 7 de marzo de 2014

II Edición del congreso Brand Care

Llega la segunda edición del congreso Brand Care, que se celebrará en Madrid los días 16 y 17 de junio. Este congreso tiene como objetivo compartir el conocimiento y experiencias de profesionales en las áreas de reputación online, ciberseguridad y legalidad en entornos digitales y móviles.
En esta segunda edición, Vicente Aguilera (director del Departamento de Auditoría de Internet Security Auditors) participará como ponente presentando una nueva versión de su herramienta "tinfoleak". Se mostrará, de forma práctica, las distintas funcionalidades que implementa y como puede ser utilizada para obtener, de forma automatizada, información privada de los usuarios de Twitter que, en muchas ocasiones, exponen sin ser conscientes de la misma y el uso que se puede hacer de ella.

jueves, 6 de marzo de 2014

MDM: Seguridad en la gestión de dispositivos móviles

1. Introducción al mundo MDM

El incremento de dispositivos móviles en las grandes corporaciones es cada día mayor. Por ello, se necesitan herramientas para controlar, monitorizar y administrar de forma fácil y segura todo el parque de terminales. Para poder realizar esta gestión existe un amplio conjunto de soluciones comúnmente llamadas MDM (Mobile Device Management), que permiten la administración de forma remota y centralizada.

Existen numerosas soluciones en el mercado. Algunas de las más conocidas se enumeran a continuación:
  • AirWatch
  • AmTel MDM
  • BlackBerry Mobile Fusion
  • Boxtone Mobile Device Management
  • Citrix XenMobile
  • Dialogs Smartman Device Management
  • Excitor DME
  • FancyFon Mobility Center
  • Fiberlink MaaS360 Mobile Device Management
  • Fixmo SafeZone
  • Good Technology Mobile Device Management
  • IBM Endpoint Manager for Mobile Devices
  • Mformation Enterprise Mobility Manager
  • Microsoft In tune
  • MobileIron MDM
  • Rapid7 Mobilisafe
  • SAP Afaria
  • SOTI Mobile Device Management
  • Symantec Mobile Management Suite
Las funcionalidades más básicas que podemos encontrar en las soluciones de los diferentes fabricantes son:
  • Control de aplicaciones: Permite a los administradores desplegar las instalaciones de forma centralizada, permitiendo y controlando aquellas que son necesarias y restringiendo de cualquier futura instalación, blindando así la posibilidad de manipulación por parte del usuario.
  • Gestión de perfiles por dispositivo: Posibilidad de pre configurar perfiles de correo, calendario, contactos, accesos VPN por terminal y/o usuario de forma centralizada, pudiendo revocar fácilmente los privilegios en casos de pérdida, robo o bajas.
  • Protección de los datos: Capacidad de forzar a utilizar el cifrado de disco y tarjeta en aquellos terminales que lo permitan.
  • Borrado seguro remoto de los datos: En caso de pérdida o robo de los terminales, se podrá gestionar la eliminación del contenido de forma remota y segura.
  • Monitorización: Capacidad de registrar las acciones producidas por el terminal, intentos de violación de la seguridad o de los mecanismos de protección, así como disponer de la geolocalización del terminal.
  • Reportes de datos: Estadística de las variables de monitorización, para conocer la evolución del estado del dispositivo.
  • Acceso a los dispositivos: Capacidad de añadir mecanismos de autenticación antes de poder acceder  a la información de los terminales.
El funcionamiento de las soluciones MDM se compone de dos elementos: cliente y servidor. Los servidores suelen estar compuestos del aplicativo de gestión del MDM, la base de datos, el panel de administración web y los servicios utilizados por los clientes como podría ser los servidores de directorio activo, de certificados, de correo, etc.

Mientras que en el lado del cliente, se suele instalar un software de gestión para poder administrar el terminal remotamente y poder hacer tareas como actualizar el software, hacer monitorización o como añadir políticas de bastionado del terminal.

Para que se pueda establecer la comunicación con los servidores, es indispensable que los clientes tengan una conexión de datos a través de telefonía móvil o de una conexión WiFi. Otra característica de la aplicación cliente es que no necesita privilegios de administrador para ejecutarse, por lo que sus funcionalidades pueden verse limitadas.

En el proceso de selección de una solución MDM se deben tener en cuenta ciertas consideraciones:
  • Soporte de múltiples dispositivos como podrían ser teléfonos y tablets con múltiples sistemas operativos. Normalmente cualquier terminal con Android, iOS o Windows Phone están soportados por los MDM.
  • Buena integración con los servicios internos corporativos que la empresa ya utiliza.
  • Garantizar la seguridad de la información interna de los dispositivos y de la transmisión de esta.
La mayoría de empresas que despliegan este tipo de soluciones proporcionan un dispositivo a cada empleado, pero también existe la posibilidad de que los empleados proporcionen su propio dispositivo (Bring Your Own Device,  BYOD). En este caso se les instala la aplicación cliente del MDM que permitiría a los terminales tener acceso a los servicios internos de la empresa y dotarlos de seguridad adicional en las comunicaciones, en el acceso físico y en la utilización de cifrado en los datos internos.

2. Aspectos de seguridad a evaluar en los MDM

En caso de querer valorar la implantación de alguna solución MDM, se deberían tener en cuenta los siguientes puntos con el objetivo de asegurarse del cumplimiento de las políticas de seguridad ofrecidas.

2.1. Dispositivos

Los terminales móviles son el eslabón más débil en la plataforma, ya que es el medio de comunicación entre los empleados y los servicios de la empresa. El análisis de seguridad de la plataforma MDM debería tener en cuenta los siguientes aspectos:
  • Control de acceso: Los terminales implementan diversos controles para limitar el acceso al propio dispositivo o a sus recursos. Entre ellos: el PIN de acceso a la tarjeta SIM, la contraseña de acceso a la partición cifrada o el mecanismo de seguridad utilizado para desbloquear la pantalla.
  • Políticas de seguridad: Fuerzan a los terminales a cumplir un mínimo de los requisitos de seguridad establecidos a nivel corporativo. Las directivas pueden ser, entre otras, denegar el acceso a instalar nuevas aplicaciones, restringir el acceso a determinadas funcionalidades (como la cámara, el thetering, bluetooth, etc.) o incrementar la complejidad de las credenciales utilizadas por el usuario.
  • Análisis de los permisos: Es conveniente estudiar si las aplicaciones permitidas en los dispositivos pueden requerir funcionalidades no necesarias para la correcta operatividad. Estas funcionalidades son requeridas en el proceso de instalación y en la ejecución de las aplicaciones. Además, se deben considerar también los permisos que las aplicaciones asignan a los recursos de disco del terminal.
  • Protecciones técnicas: Son todas aquellas medidas generales que pretenden incrementar el nivel de seguridad y que se deberían analizar:
    • Seguridad del sistema: El acceso a procesos en ejecución, el acceso a ficheros o directorios, la ejecución de aplicaciones no firmadas, la configuración del firewall, etc.
    • Seguridad de los datos: El cifrado de los datos almacenados, el borrado remoto en el caso de pérdida o robo, o el borrado automático de los datos en caso de que se sobrepase el número máximo de intentos erróneos de acceso.
    • Aplicaciones de seguridad externas o complementarias: Por ejemplo, los antivirus así como todas las aplicaciones que aporten una capa extra de seguridad.
  • Análisis de las contraseñas: Los terminales pueden ser entregados a los empleados con una contraseña (de bloqueo o de cifrado) que pueda resultar poco robusta o, incluso, pueda ser la contraseña por defecto del terminal. Es por ello que se debe validar la existencia de políticas de bastionado que garanticen unos mínimos niveles de seguridad. Por ejemplo, a nivel de contraseñas, podría ser el uso de credenciales con caracteres alfanuméricos y signos de puntuación, una longitud mínima de diez caracteres, etc.
  • Análisis de datos: Se debe contemplar el análisis sobre los sistemas de ficheros con el objetivo de encontrar fugas de información que puedan haber generado las aplicaciones. Por ejemplo, ficheros temporales o ficheros con credenciales (cifradas o no), información sensible en ficheros de log, contenidos de bases de datos o ficheros XML, etc.
  • Análisis de la navegación por Internet: Si los dispositivos utilizan redes WiFi, las comunicaciones pueden ser interceptadas. Todas las comunicaciones deberían realizarse cifradas y los dominios permitidos deberían gestionarse a través de ACL en la pasarela proxy.
  • Análisis de la aplicación cliente: Se debe analizar el funcionamiento interno de la aplicación para verificar que las especificaciones de seguridad descritas en el producto realmente se cumplen. Sobretodo es importante verificar la seguridad del proceso de registro del terminal (enrollment) en el MDM .
  • Actualizaciones de aplicaciones y del sistema: Debe existir un mecanismo que, de forma transparente, aplique parches de seguridad en el sistema así como las actualizaciones de las aplicaciones.

2.2. Infraestructura y servidores

Dado que la solución MDM debe integrarse con la infraestructura existente, resulta necesario evaluar este proceso así como los elementos afectados. El análisis de seguridad de la infraestructura y servidores debería tener en cuenta los siguientes aspectos:
  • Análisis de la arquitectura y comunicación entre plataformas: Analizar los componentes de la infraestructura y cómo se establece la comunicación entre ellos. Dado que las comunicaciones deben ser cifradas es necesario incluir en el análisis los certificados utilizados. Este análisis implica también identificar y validar los protocolos de red utilizados, identificar deficiencias en los mismos, validar la información que se transmite entre los distintos elementos, así como analizar los canales confiables.
  • Análisis a nivel de servidor: Analizar el nivel de seguridad que ofrecen los servidores incluye tanto la evaluación del propio sistema como la de la aplicación que gestiona la plataforma MDM. Típicamente, esta evaluación se realiza mediante la ejecución de un test de intrusión (simulando la acción de un usuario malicioso que quisiera comprometer el sistema o la aplicación). Para ello es importante seguir metodologías alineadas con las buenas prácticas de la industria como, por ejemplo,  OSSTMM (Open Source Security Testing Methodology Manual, www.osstmm.org), PTES (Penetration Testing Execution Standard, www.pentest-standard.org) y Testing Guide de OWASP (Open Web Application Security Project, www.owasp.org).

3. Conclusiones

Debido a las necesidades de movilidad de los usuarios, la potencia de los terminales (y su rápida evolución) así como el hecho de requerir gestionar estos dispositivos de forma centralizada y segura, podemos predecir un claro incremento del nivel de implantación de las infraestructuras MDM en muchas organizaciones, en especial, en aquellas con un elevado número de empleados.

No descubrimos nada nuevo si hablamos de las bondades que aportan este tipo de soluciones a nuestra organización (asociadas a la gestión centralizada de la seguridad de nuestro parque de terminales), pero debemos ser conscientes que, como cualquier otro componente de nuestra infraestructura, puede sufrir vulnerabilidades y, por lo tanto, debe ser evaluado periódicamente y deben adoptarse las medidas que nos permitan solucionar o mitigar las deficiencias identificadas. Dicha evaluación debe realizarse sobre todos los elementos involucrados en la infraestructura MDM, y deben incluir la revisión, entre otros, de aspectos relacionados con deficiencias de configuración, ausencia de actualizaciones o incumplimientos de la política corporativa.

La solución MDM nos brinda opciones interesantes a nivel de securización y control de nuestro parque de terminales, pero no debemos olvidar que su eficiencia dependerá, en última instancia, de las políticas de seguridad existentes, la configuración que se establezca y del nivel de seguridad de nuestra infraestructura en general.


Autor: Tomás Velázquez - CEH
Departamento de Auditoría

miércoles, 5 de marzo de 2014

Nuevo SAQ A-EP de PCI DSS v3.0 para empresas de E-Commerce con pago externalizado

El PCI SSC, con la publicación de los nuevos Cuestionarios de AutoEvaluación (SAQ) para el reporte del cumplimiento de PCI DSS v3.0 ha dado un paso más en la adaptación de los cuestionarios a las casuísticas existentes en las empresas que han de presentar este reporte y, muy en concreto, en cuanto a comercios.

Hasta ahora, los comercios, cuyo estado de cumplimiento ha de ser reportado a las entidades bancarias, de las que son clientes, disponía de cinco cuestionarios (A, B, C, C-VT y D), muy a grandes rasgos, siendo el A el utilizado para aquel comercio presencial que no recogía datos de tarjeta (y por tanto el cuestionario y reporte más "sencillo") y el D para el comercio que, habitualmente, almacenaba el dato (y por tanto el cuestionario y reporte más "amplio y/o complejo").

Pero en los comercios electrónicos se producía una paradoja en los casos en los que estos integraban el uso de un Terminal de Punto de Venta (TPV) Virtual, al que redirigen al cliente para realizar el pago: dado que no obtenían el dato (siempre que ellos no pidieran los datos de pago y fuera el TPV de una entidad, procesador, IPSP el que lo hiciera) se trasladaba la incorrecta sensación que este comercio no tiene ni responsabilidad ni riesgo en el compromiso del dato de tarjeta.

El año pasado, dentro del E-Commerce Special Interest Group (SIG) del PCI SSC, en el que participó un miembro del equipo de Internet Security Auditors, se estuvo tratando el cómo definir las responsabilidades de las empresas de E-Commerce. Una conclusión clave resultante del trabajo de este SIG, y que así se incluyó en el documento final, fue que: "Ninguna opción [de método de pago que se haya implementado] elimina completamente las responsabilidades de cumplimiento de PCI DSS del comercio". Esta Guía  se publicó en enero de 2013 en la web del PCI SSC con el nombre  de "PCI DSS E-commerce Guidelines" que se puede descargar en https://www.pcisecuritystandards.org/pdfs/PCI_DSS_v2_eCommerce_Guidelines.pdf.

A los comercios, en algunos casos, se les ha trasmitido la falsa sensación que, empleando ese TPV o solución de pago de terceros, se les eximía del cumplimiento de cualquier responsabilidad de cumplimiento de PCI DSS. Pero un escenario relevante se obviaba en esta situación: dado que desde esa web es desde donde se redirige al cliente que realiza el pago a la web del tercero (en el que se introducen los datos de pago) existen técnicas en las que vulnerando y comprometiendo el sitio del primero, es posible capturar los datos de pago, de forma transparente para el usuario, y redirigiendo el pago a la web de la entidad, ISPS o tercero, ese sí, cumplidor de PCI DSS.

El esquema sería el siguiente:
Nuevo SAQ A-EP de PCI DSS v3.0 para empresas de E-Commerce con pago externalizado

El PCI SSC, el mes de febrero, en sus circulares a QSA y empresas miembro del consejo, ha incluido en su sección de "Pregunta del mes" la respuesta a esta situación y que dice:

¿Si un sitio web utiliza una redirección a un página de pago alojada en un tercero, está el servidor web en el ámbito de aplicación de la versión 3.0 de PCI DSS?
Cuando las páginas web utilizan páginas de pago alojada en un tercero al que redirigen el procesamiento de pagos, existe el riesgo de que la página web puede verse comprometida como resultado la recolección no autorizada de los datos de titulares de tarjetas antes o durante la redirección. El uso de un servidor web para redirigir los datos de titulares de tarjetas a un tercero, por tanto, no elimina del servidor web del comercio del ámbito de aplicación y los requisitos de PCI DSS aplicables debe ser implementados. [....]

Añadido a esto, y como mencionábamos al principio de este artículo, esta misma semana, el PCI SSC ha publicado los SAQ de la versión 3.0 y una de las novedades de estos cuestionarios es la aparición del nuevo modelo SAQ A-EP, que define los requerimientos potencialmente aplicables para los Comercios E-Commerce Externalizados Parcialmente Empleando Sitios Web de Terceros para el Procesamiento del Pago ("Partially Outsourced E-commerce Merchants Using a Third-Party Website for Payment Processing"). Esto quiere decir que, de ahora en adelante, los comercios que, hasta ahora se encontraban en una cierta indeterminación (por el mensaje trasladado hacia ellos sobre la necesidad de cumplimiento) tendrán más claro el escenario y responsabilidades de cumplimiento que les aplica. Este cuestionario puede descargarse ya desde la web del PCI SSC e incluye 139 controles que, según el caso particular, habrá que analizar su grado de aplicación concreta a cada empresa que realiza comercio electrónico.

Clarificar las cosas no debe ser sinónimo de complicación sino al contrario, que los comercios tengan claras las responsabilidades servirá para proteger a los comercios y a los clientes, sobre todo para que, si se produce un  incidente con un compromiso de datos, todas las partes tengan claro a qué atenerse.

martes, 4 de marzo de 2014

Ampliamos el Acuerdo de Colaboración con el Col·legi Oficial de Enginyers de Informàtica de Catalunya

Hemos ampliado nuestro Acuerdo de Colaboración con el Col·legi Oficial de Enginyers de Informàtica de Catalunya  para incluir las últimas certificaciones y cursos que ofrecemos.

De esta forma, se incluyen las certificaciones CSSLP y CCFP del (ISC)2, la certificación ISO 22301 Lead Auditor de BSI y el curso preparatorio para PCIP.

Además, desde el 1 de marzo de 2014, los que participen en cursos con nosotros y quieran colegiarse, tendrán un año de cuotas gratis. ¡Aprovecha la oferta!

Para más información: http://enginyeriainformatica.cat/?page_id=210
Para colegiarse o adherirse al Colegio: http://enginyeriainformatica.cat/?page_id=6241 o http://enginyeriainformatica.cat/?page_id=11014.