Junio de 2014IBM Security Systems

Informe IBM X-Force Threat Intelligence del segundo trimestre de 2014Descubra cómo están evolucionando las vulnerabilidades de las aplicaciones, las amenazas de spam y la respuesta a incidencias según los últimos datos y un análisis actual

2 Informe IBM X-Force Threat Intelligence del segundo trimestre de 2014

2 Resumen ejecutivo

4 Aplicaciones vulnerables como vector de una grave amenaza

9 El spam y su persistencia en el tiempo

14 Cinco consideraciones principales cuando la respuesta remota a las incidencias se vuelve extremadamente remota

18 Información sobre X-Force

19 Colaboradores

19 Más información

El equipo de Investigación y Desarrollo de IBM® X-Force®, junto con sus compañeros de la división IBM Global Technology Services®, lleva mucho tiempo dedicado al análisis de las nuevas amenazas a la seguridad. Por ello nos complace compartir nuestros últimos hallazgos. A principios de 2014, empezamos a profundizar en los numerosos problemas e incidencias de seguridad que siguen poniendo en peligro a las organizaciones. En este informe del segundo trimestre de 2014, centramos nuestra atención en los métodos que permiten que los ataques cosechen el éxito obtenido en el pasado y en los problemas ligeramente nuevos que deben tenerse en cuenta en el panorama de seguridad actual.

En primer lugar, echemos un vistazo a las amenazas antiguas. A lo largo del tiempo, hemos presenciado cómo las amenazas van reemplazándose unas a otras. Los famosos mensajes de correo electrónico infectados como ILOVEYOU han evolucionado a insidiosas instalaciones de malware por descarga que recopilan, de forma silenciosa, los datos confidenciales del usuario. La deformación de sitios web solo para alardear ha pasado a ser una distracción para llevar a cabo actividades más maliciosas contra servidores y bases de datos. Asimismo, los gusanos como Blaster y St0rm establecieron el marco de los últimos ataques de denegación de servicio distribuido (DDoS).

¿Qué conclusión podemos sacar del historial de amenazas en Internet y de cómo han cambiado las cosas? Las aplicaciones son vulnerables desde el mismo momento de su creación. Cuando los programadores escriben software y cometen errores, las aplicaciones ya son vulnerables. En este informe, estudiaremos con mayor profundidad las aplicaciones de sitios web vulnerables y cómo siguen siendo un vector de amenazas para los atacantes que buscan dañar a las organizaciones o robar sus datos confidenciales.

Resumen ejecutivoContenido

IBM Security Systems 3

El análisis de las aplicaciones puede ayudar a proteger la mayor parte de los componentes más importantes para el usuario, ya que aborda tanto el código personalizado de la aplicación como los componentes de terceros. Aun así, los clientes deben tener en cuenta la seguridad del servidor web en sí. La tecnología vulnerable, que compone el eje central de un conjunto de aplicaciones web, puede poner en peligro a todo el entorno.

En abril de 2014, una vulnerabilidad (CVE-2014-0160) encontrada en OpenSSL (un software popular y comúnmente utilizado) puso en peligro a un enorme porcentaje de sitios web y los expuso a pérdidas de información confidencial y de vital importancia. El parche en sí no era difícil de aplicar, pero la mitigación de los posibles daños por revelar credenciales de usuario, certificados SSL y otra información confidencial hizo que la solución del problema supusiera todo un desafío. Cuando se anuncian vulnerabilidades críticas o se producen incidencias, deberíamos aprender a “esperar lo inesperado”. Si crea una respuesta a incidencias basada en la planificación de situaciones conocidas, está perdido. El contenido de la memoria de acceso aleatorio (RAM) es ahora tan valioso como los datos almacenados en el disco. Proporcionaremos algunas recomendaciones para las organizaciones que deseen mejorar en esta importante área de seguridad.

Para obtener más información sobre Heartbleed, la vulnerabilidad TLS de Open SSL, consulte la entrada sobre este tema en el blog de IBM Security Intelligence.1

En la siguiente sección del informe, nos centraremos en el spam (una de las amenazas de seguridad más antiguas y duraderas) y en cómo es posible que siga entre nosotros. Si bien la mayoría de las organizaciones cuentan con los controles adecuados para mantener a raya el spam, los atacantes siguen usándolo para saturar los servidores de correo electrónico y, en ocasiones, enviar cargas dañinas a usuarios desprevenidos. El equipo de seguridad de contenidos IBM X-Force sigue supervisando la evolución del spam y cómo se mantiene como un canal principal de inserción de malware en las redes de las compañías. En marzo de 2014, pudimos contemplar el retorno de los niveles más altos de spam registrados en los últimos dos años y medio. También analizamos los datos de seguimiento de

infecciones de robots de spam y su relación con la reciente finalización del soporte para Microsoft Windows XP.

Por último, cerraremos el informe con una categoría prácticamente nueva de las amenazas de seguridad. Con la ayuda del equipo Emergency Response Services (ERS) de IBM Global Technology Services, compartiremos las lecciones aprendidas cuando la respuesta remota a incidencias se vuelve demasiado remota. A medida que las organizaciones de todo el mundo amplían su alcance a países en desarrollo y nuevas infraestructuras, ¿qué sucede cuando se produce una incidencia de seguridad en un área con limitaciones en comunicaciones y ancho de banda? ¿Cómo pueden los programas de respuesta transferir rápidamente sus datos más importantes? Explicaremos el modo en el que la respuesta a incidencias en países remotos o ubicaciones con infraestructuras deficientes requiere una estrategia única.

4 Informe IBM X-Force Threat Intelligence del segundo trimestre de 2014

Desde las vulnerabilidades de inyección hasta la autenticación interrumpida: descubra qué amenazas pueden estar acechando en sus aplicaciones web dinámicas.

Aplicaciones vulnerables como vector de una grave amenaza

Los atacantes buscan cualquier ruta de acceso para adueñarse de datos confidenciales y valiosos para las empresas. Con frecuencia, el camino más rápido a los sistemas internos de

una empresa es a través de vulnerabilidades como la inyección de código SQL (SQLi) y la autenticación interrumpida. Si las empresas no prueban sus sitios web ni las aplicaciones que acceden a los datos, corren el riesgo de exponer activos valiosos.

En el mundo de las aplicaciones móviles, por ejemplo, los investigadores de IBM han encontrado recientemente una serie de vulnerabilidades en Mozilla Firefox para Google Android que permitían a las aplicaciones malintencionadas filtrar información confidencial sobre los perfiles de los usuarios.2 Un atacante puede aprovechar estas vulnerabilidades para extraer información como cookies y datos almacenados en caché, como el historial del explorador y los ID de usuario.

Otra vulnerabilidad móvil detectada por los investigadores de IBM es la inyección de fragmentos en el marco de Android que afectaban a numerosas aplicaciones populares, incluidas Google Now, Gmail, Dropbox y Evernote.3 Los atacantes que aprovecharon esta vulnerabilidad pudieron acceder a información confidencial de la aplicación vulnerable al romper el espacio aislado de Android.

Las aplicaciones web son otro objetivo atractivo para los ejecutores de amenazas, ya que suelen tener acceso a datos empresariales valiosos almacenados de forma interna. Aprovechar una vulnerabilidad de inyección, como SQLi, puede conducir a la manipulación de bases de datos de fondo protegidas. Asimismo, una protección incorrecta de los datos en tránsito de entrada y salida de una aplicación web puede dar lugar a fugas de datos de las credenciales de usuario, datos de tarjetas de crédito y comunicaciones privadas.

¿Cuáles son las 10 amenazas principales de las aplicacio-nes web?

En 2013, la clasificación del Open Web Application Security Project (OWASP) proporcionó una lista con los 10 riesgos de seguridad de aplicaciones web más importantes. Tal y como se muestra en la ilustración 1, los ataques de inyección, la administración de sesiones y de autenticación interrumpida, así como las secuencias de comandos de múltiples sitios ocupaban los primeros puestos de la lista.4

En las siguientes secciones abordaremos con mayor profundidad la investigación del equipo de IBM sobre las amenazas de aplicaciones web, realizada con pruebas de aplicaciones alojadas.

Datos de amenazas de aplicaciones webEl servicio Hosted Application Security Management (HASM) de IBM es una solución basada en la nube para la prueba dinámica de aplicaciones web mediante IBM Security AppScan® en entornos de preproducción y producción. Los servicios HASM incluyen un analista de seguridad especializado que configura y administra la prueba.

Para este informe, el equipo HASM recopiló datos de más de 900 análisis de aplicaciones web dinámicas realizados en 2013. Algunos puntos clave sobre estos datos:

• El conjunto de datos engloba una gran variedad de sectores,incluidos el gubernamental, los servicios financieros,industrial, farmacéutico, comercio minorista ytelecomunicaciones.

• La mayoría de los análisis los realizan organizaciones quellevan más de cinco años usando el servicio HASM. Estoimplica que han madurado y establecido prácticas deseguridad, lo que quiere decir que las aplicaciones analizadassuelen tener menos vulnerabilidades que las de unaorganización nueva en la seguridad de aplicaciones web.

• Si bien el análisis de las aplicaciones web de estasorganizaciones se realiza de forma regular, se siguenencontrando vulnerabilidades continuamente, a menudointroducidas por cambios de código o por la implementaciónde nuevas aplicaciones. Por ello, las aplicaciones deberíanvolver a analizarse después de la implementación de nuevasfuncionalidades, así como de actualizaciones y revisiones decódigos.

• La mayoría de los problemas encontrados están relacionadoscon la falta de una validación y depuración adecuadas.

2013: El año de la amenaza de la autenticación interrumpidaLa ilustración 1 muestra que las amenazas de secuencias de comandos de múltiples sitios (XSS) y falsificación de solicitud en múltiples sitios (CSRF) siguen bastante presentes en las aplicaciones web. Los ataques de inyección, aunque menos frecuentes en este conjunto de muestra, siguen siendo comunes y peligrosos, ya que conducen directamente a los atacantes a los datos internos y confidenciales. No obstante, puesto que estas vulnerabilidades son bastante conocidas, veremos en mayor profundidad otro problema también prevalente: la autenticación interrumpida.

La autenticación interrumpida puede producirse por la incorrecta protección de las credenciales de contraseña e ID de usuarios, así como por una administración inadecuada de los ID de sesión. Si no se protege correctamente la información de autenticación, un atacante puede secuestrar una sesión de usuario y hacerse pasar por ese usuario. Por ejemplo, el ejecutor de una amenaza puede aprovechar esta vulnerabilidad para hacerse cargo de una sesión de banca electrónica y transferir fondos como si el atacante fuera el usuario legítimo.

Los datos de HASM destacan que uno de los errores más comunes de la autenticación interrumpida detectado en los análisis es “ID de sesión no actualizado durante el inicio de sesión”. Esta particular prueba se asegura de que el valor de la cookie de la sesión se actualiza durante la secuencia de inicio de sesión; es decir, después de que un usuario haga clic en el botón “Enviar” en una página de inicio de sesión. Si el ID de sesión (SID) no se actualiza en el inicio de sesión, la aplicación web puede ser vulnerable a ataques de fijación de sesión. En un ataque de fijación de sesión, si los atacantes pueden acceder a un SID válido, pueden usar ese ID para saltarse el proceso de inicio de sesión y acceder a la cuenta de la víctima. Este ataque puede funcionar con SID generados tanto por el usuario como por el servidor.

Las aplicaciones de Microsoft ASP.NET suelen ser vulnerables a ataques de fijación de sesión ya que, normalmente, el valor de cookie JSESSION se genera en la página de inicio de sesión antes de que el usuario inicie sesión y, de forma predeterminada, no se actualiza durante el proceso de inicio de sesión.

IBM Security Systems 5

% de aplicaciones web analizadas con amenazas

Ilustración 1. Vulnerabilidades más comunes detectadas en aplicaciones web según el servicio IBM Hosted Application Security Management (HASM) en comparación con las 10 principales vulnerabilidades OWASP observadas durante 2013

Conclusiones de 2013 de las 10 principales vulnerabilidades según OWASP

0% 5% 10% 15% 20% 25%

A1 InyecciónA2 Errores de autenticación y

administración de sesiones

A3 Secuencias de comandos en sitios cruzados (XSS)

A4 Referencias directas a objetos no seguras

A5 Configuraciones de seguridad incorrectas

A6 Exposición de datos confidenciales

A7 Ausencia de control de acceso de nivel de funciones

A8 Falsificación de petición en sitios cruzados (CSRF) A9 Uso de componentes con

vulnerabilidades

A10 Redirecciones y reenvíos no validados

6%

23%

23%

17%

0%

0%

7%2%

14%

1%

La fijación de sesión y el uso incorrecto de los SID son una vulnerabilidad común. También hemos comprobado que este problema en concreto no se conoce bien y suele requerir unas cuantas interacciones antes de que los desarrolladores lo entiendan y solucionen correctamente.

Para ayudar a mejorar la prueba de aplicaciones para la detección y solución tempranas de las vulnerabilidades de autenticación basada en sesión, IBM recomienda:

1. Actualizar el SID en el inicio de sesión2. Establecer un límite de tiempo en el SID tras el cierre de

sesión o un período de inactividad3. Proporcionar interfaces de programación de aplicaciones

(API) o bibliotecas para las funciones de autenticación

Tendencias en las pruebas de seguridad de las aplicacionesAl igual que crece la concienciación sobre la seguridad en las aplicaciones, también lo hacen las tendencias hacia la inversión en el análisis de aplicaciones web. Las organizaciones desarrollan una línea de base del riesgo de su aplicación web añadiendo un análisis regular de la aplicación en entornos de preproducción o de producción.

Tradicionalmente, los clientes de HASM están más interesados en analizar sus aplicaciones antes de la implementación. Sin embargo, en el pasado año, hemos visto un aumento diferente en las organizaciones que desean realizar un análisis continuo a gran escala de sus sitios en funcionamiento.

Para facilitar estas iniciativas de análisis masivo de sus aplicaciones, las organizaciones deben crear un inventario de todas las aplicaciones web que usen un método automatizado de detección de aplicaciones. Para el personal de seguridad de TI es cada vez es más difícil supervisar o encontrar todas las aplicaciones web a su cargo. No es poco común que las organizaciones subestimen hasta en un 50 % el número de aplicaciones web que tienen. Además, si no sabe que tiene una aplicación en funcionamiento, es bastante seguro que no esté analizando sus vulnerabilidades de seguridad. No obstante, los atacantes sí están analizando esas vulnerabilidades. Por ello es tan importante realizar un análisis y una actualización periódicos de la información de inventario de las aplicaciones.

Puesto que el análisis de aplicaciones web requiere unas competencias específicas, una inversión importante en software y, quizás, una infraestructura adicional, muchas organizaciones

usan un modelo externalizado. Crear equipos internos con conocimientos especializados de pruebas de seguridad de aplicaciones puede resultar costoso y requerir mucho tiempo. Por ello, subcontratar el trabajo permite a las organizaciones ponerse en marcha de forma rápida y a un precio asequible. Además del poco tiempo de puesta en funcionamiento, los proveedores de pruebas tienen amplios conocimientos y experiencia en seguridad. Asimismo, ofrecen un mantenimiento continuo del software de análisis y de la infraestructura necesaria.

Consejos para el análisis seguro de producciónAl usar un análisis externalizado, es importante entender la naturaleza del análisis que se está realizando. Hable con el equipo de pruebas para comprender cómo se están configurando los análisis, qué se está probando, si hay algo que no se esté probando y qué cobertura se está obteniendo. A continuación, pregunte si existe algún riesgo o dificultad. Este último punto es especialmente importante, ya que las aplicaciones de prueba que se encuentran en producción pueden dar lugar a incidencias en el servicio. Cuando evalúe a los proveedores, asegúrese de conocer su enfoque de análisis de producción y la cobertura de sus pruebas.

Análisis de producciónSi un proveedor recomienda el análisis de producción, debe tener en cuenta algunos factores clave. Para un sitio web con contenido estático, hay menos de lo que preocuparse; sin embargo, en el caso de aplicaciones que recopilan datos y los guardan en bases de datos de fondo o alimentan esos datos con otros sistemas de fondo, es importante saber cómo van a probarse estas áreas. El análisis de producción tiene dos enfoques principales:

1. Prueba de formularios completos: según este enfoque, seprueban todos los formularios de su aplicación. Si bien esteenfoque puede ofrecer una buena cobertura y encontrar lamayoría de los problemas, existen muchos riesgos:

– Cuando se envían los datos a una base de datos mediante formularios, la prueba puede hacer que se inserten muchos datos de la prueba en los sistemas y la base de datos de fondo. Por ejemplo, un formulario con 10 campos puede enviarse más de 1000 veces.

6 Informe IBM X-Force Threat Intelligence del segundo trimestre de 2014

IBM Security Systems 7

– Algunos formularios se usan para enviar directamente correos electrónicos o para vincularse a otros sistemas de fondo que generan el correo electrónico. De nuevo, si se prueban estos formularios, pueden generarse miles de correos electrónicos.

– Aunque es raro, es posible que los análisis provoquen un fallo completo de las aplicaciones o los sistemas de fondo. Incluso si no fallan, los datos de prueba que se insertan pueden causar errores en el procesamiento de fondo.

– El análisis de seguridad de aplicaciones web puede generar grandes cantidades de tráfico http(s) y generar problemas de rendimiento o de ancho de banda en algunas aplicaciones, lo cual puede afectar directamente a sus usuarios.

2. Sin rellenado de formularios o rellenado selectivo deformularios: según este enfoque, el rellenado de formularioses mínimo o inexistente, lo cual puede evitar los problemas dela prueba de formularios completos. No obstante, este tipo depruebas es menos exhaustivo y puede dar lugar a brechas deseguridad. Los formularios suelen ser las áreas de unaaplicación en la que se encuentran muchos problemas críticos,debido a una validación inadecuada de los datos introducidos.Al no probar todos los formularios, las organizaciones correnel riesgo de pasar por alto estos problemas importantes.

La ilustración 2 muestra el punto en el que se encuentran menos vulnerabilidades cuando el análisis de producción se realiza de esta forma para reducir los posibles problemas de la prueba de formularios completos.

5%

Ilustración 2. Resultados de los análisis de producción y preproducción obtenidos por el servicio IBM Hosted Application Security Management (HASM) en comparación con las 10 principales vulnerabilidades OWASP observadas durante 2013.

Resultados de las 10 principales vulnerabilidades según OWASP por tipo de prueba

Conclusiones de promedio por prueba

Producción Preproducción

A1 Inyección

A2 Errores de autenticación y administración de sesiones

A3 Secuencias de comandos en sitios cruzados (XSS)

A4 Referencias directas a objetos no seguras

A5 Configuraciones de seguridad incorrectas

A6 Exposición de datos confidenciales

A7 Ausencia de control de acceso de nivel de funciones

A8 Falsificación de petición en sitios cruzados (CSRF)

A9 Uso de componentes con vulnerabilidades

A10 Redirecciones y reenvíos no validados

0% 5% 10% 15% 20% 25% 30% 35% 40%

12%20%

38%

28%15%

1%5%

5%13%

12%27%

20%38%

0%0%

1%0%

1%4%

8 Informe IBM X-Force Threat Intelligence del segundo trimestre de 2014

Debido a los problemas asociados a la prueba de formularios completos, suele ser ventajoso ejecutar análisis en un entorno de ensayo o de control de calidad antes de la implementación. El análisis de preproducción puede complementarse con otros análisis periódicos discretos (sin rellenado de formularios) en aplicaciones de producción. Este enfoque permite probar por completo las aplicaciones sin correr el riesgo de dañar los datos o de causar interrupciones en los sistemas de producción.Además, también admite la prueba y la supervisión continuas.

CoberturaOtro aspecto que debe tenerse en cuenta es el área de cobertura real para la prueba: por ejemplo, ¿cubre la prueba solo las páginas web, o también incluye las áreas dinámicas? No debe darse por sentado que los análisis cubrirán el 100 % de las aplicaciones. Hay muchas formas de enfocar el análisis de aplicaciones y, si no se hace correctamente, los análisis pueden tener importantes ángulos muertos y dejarle expuesto.

Como se ha mencionado anteriormente, los análisis pueden realizarse en entornos de producción y de preproducción. Dada la necesidad de proteger los entornos en funcionamiento, los análisis de producción suelen estar diseñados para ofrecer una cobertura limitada. Sin embargo, los análisis de preproducción deberían realizarse de una forma más intrusiva, especialmente cuando se trata de rellenado de formularios. Si conoce la configuración del análisis que se está usando en preproducción y en producción, puede asegurarse de que su cobertura es la adecuada.

En lo que respecta al rellenado de formularios para aplicaciones web dinámicas, el uso de un mecanismo de rastreo automático suele ser insuficiente para las pruebas. Las aplicaciones muy dinámicas requieren datos de formularios específicos, y la interfaz de usuario (IU) suele ser demasiado sofisticada para que un mecanismo de rastreo automático navegue correctamente por esta para probar todas las funcionalidades. Esto significa que, para obtener una cobertura completa de prueba para estas aplicaciones, debe ampliar el mecanismo de rastreo automático con un rastreo manual por parte de un profesional de pruebas de seguridad cualificado.

Por último, desde una perspectiva de cobertura de páginas, es importante saber qué filtrado se está aplicando al análisis. Los ajustes en la configuración de análisis pueden filtrar páginas por similitud y otra redundancia de URL. Aunque el filtrado es una buena herramienta para garantizar rápidamente que los análisis están optimizados, también puede limitar la cobertura.

Estos ajustes suelen realizarse manualmente y pueden requerir que se apliquen de forma distinta en función del sitio web.

Recomendaciones finalesLas aplicaciones son un objetivo clave para los atacantes. Si no se prueban y solucionan sus vulnerabilidades de seguridad, los atacantes pueden encontrar y usar una ventana para actuar. Recientemente, los investigadores de IBM detectaron vulnerabilidades tanto en el marco de Android como en el explorador de Firefox que ponían en peligro los datos corporativos de los dispositivos móviles. De forma similar, el equipo de servicios HASM de IBM, que usa AppScan para las pruebas, observó que las vulnerabilidades de inyección y la autenticación interrumpida están activas en muchas aplicaciones web en entornos de producción. La mejor manera de evitar las amenazas (y proteger los datos accesibles desde dispositivos móviles y aplicaciones web) es buscar vulnerabilidades en sus aplicaciones y solucionar las que encuentre.

IBM Security Systems 9

El spam y su persistencia en el tiempo¿Cuáles son las últimas tendencias en spam? Aprenda cómo los atacantes están reinventando las formas de explotar el buzón de entrada de correo electrónico y eludir la detección.

Desde sus orígenes a finales de los 70, la batalla entre los creadores de spam y los sistemas de detección de spam ha sido incesante. Si observamos los avances más

recientes de la última década, el informe X-Force 2011 Trend and Risk Report de IBM realizó un exhaustivo análisis de la evolución del spam, incluidas las tendencias a largo plazo, las técnicas y las fluctuaciones del volumen general.

Ahora, unos años después, seguimos viendo cómo vienen y van algunas de estas mismas tendencias. El spam de texto sin formato y el spam con archivos adjuntos comprimidos infectados siguen reinando, y los atacantes siguen encontrando nuevas formas de eludir la detección. Otras técnicas, como el envío de archivos MP3 o archivos adjuntos en PDF, no han sido tan eficaces. El spam basado en imágenes, que apareció por primera vez en 2005, ha seguido apareciendo con distintas

formas. Ya sea promocionando acciones de compraventa o mediante vínculos a contenido malintencionado, seguimos viendo cómo los atacantes exploran nuevas formas de explotar el buzón de entrada de correo electrónico para obtener la máxima eficacia.

Otra visión de los orígenes del spam El spam ha sido y es un grave problema, ya que sigue representando el canal principal de malware en las redes de las compañías. En marzo de 2014 se registraron los niveles más altos de spam de los dos últimos años y medio. La ilustración 3 muestra los principales países en los que se ha originado el spam en los últimos seis meses. Además, muchos países incluidos en el pasado siguen siendo los principales infractores en la actualidad (para obtener más información sobre los países donde se origina el spam, consulte el informe X-Force 2013 Mid-Year Trend and Risk Report de IBM).

49,1%

Ilustración 3. 10 principales países desde los que se origina el spam, del 4º trimestre de 2013 al 1er trimestre de 2014.

10 principales países desde los que se origina el spam, del 4º trimestre de 2013 al 1er trimestre de 2014.

10,1%

6,2%

6,2%

5,7%

4,5%

4,4%

4,3%

3,4%

3,1%

3,0%

Otros

EspañaItalia

Estados Unidos

India

Alemania

RumaníaArgentina

Vietnam

Rusia

Reino Unido

10 Informe IBM X-Force Threat Intelligence del segundo trimestre de 2014

Infecciones de robots de spam y fin del soporte para Windows XPOtra interesante perspectiva es la que se obtiene al calcular el porcentaje de equipos (o direcciones IP) que envían spam. Si comparamos el número de direcciones IP que realizaron ataques de spam en los últimos seis meses con el total de direcciones IP del país, obtenemos las cifras que se muestran en la ilustración 4.

Pese a que cada país que figura en la ilustración 4 es el origen de menos del tres por ciento del spam mundial (salvo La India y Vietnam), el índice de equipos infectados con robots de spam en estos países es alarmantemente alto. Esto puede deberse a que muchos equipos no utilizan las actualizaciones o los sistemas operativos más recientes. En la actualidad, aproximadamente el 18,4 por ciento de los equipos de todo el mundo aún usa Windows XP.5 Sin embargo, en 16 de los 20 países enumerados en la ilustración 4, el uso de Windows XP

es superior a la media mundial. En algunos casos, el uso llega a superar el 30 por ciento hasta llegar al 42,2 por ciento en Vietnam.

El 8 de abril de 2014, Microsoft anunció el fin del soporte para el sistema operativo Windows XP.6 Muchas organizaciones han sido conscientes de la fecha de fin de soporte y han migrado sus bases de usuarios a versiones más recientes. Sin embargo, existen otras organizaciones que siguen con dificultades (o que, por elección propia, no han tomado medidas) para dejar Windows XP atrás. Además, para determinados sectores como por ejemplo, la banca, el software industrial o la sanidad, el anuncio del fin de Windows XP es un verdadero problema. Por ejemplo, el 95 por ciento de los cajeros basados en EE. UU. siguen usando Windows XP y son, por tanto, susceptibles de convertirse en objetivos de ataques.7 Estas organizaciones están obligadas a afrontar los retos de un mundo post-Windows XP.

Arm

enia

Ilustración 4. Comparación de los 20 países con mayor índice de infecciones con robots de spam con el uso de Windows XP, desde el 4º trimestre de 2013 hasta el 1er trimestre de 2014.

20 países con mayor número de infecciones con robots de spam, comparados con el uso de Windows XPDesde el 4º T. de 2013 al 1er T. de 2014

45%

40%

35%

30%

25%

20%

15%

10%

5%

0%Ur

ugua

y

Iraq

Liby

aVi

etna

mLe

bano

nSe

nega

l

Indi

a

Tuni

sia

Porcentaje de IP implicadas en el envío de spam Porcentaje de uso de Windows XP Uso de Windows XP, promedio mundial†

*Datos tomados de los informes “StatCounter Global Stats: Top Desktop, Tablet and Console OSs Per Country from Oct to Dec 2013” and “StatCounter Global Stats: Top Desktop, Tablet and Console OSs Per Country from Jan to Mar 2014,” StatCounter, fecha de acceso del 14 de mayo de 2014.† “StatCounter Global Stats: Top 7 Desktop, Tablet and Console OSs from Oct 2013 to Mar 2014,” StatCounter, fecha de acceso del 17 de abril de 2014.

IBM Security Systems 11

Desde otro punto de vista, en muchos casos, el uso de Windows XP también está relacionado con aquellos países en los que se origina mayor volumen de spam. Las estadísticas indican lo siguiente:

• Existen numerosas pruebas de la existencia de infecciones derobots de spam.

• El uso de aplicaciones y sistemas operativos actualizados, juntocon el mantenimiento y la aplicación de parches yactualizaciones de seguridad más recientes, siguen siendo lasopciones más eficaces para proteger tanto a los destinatarioscomo a los servidores vulnerables del spam.

El regreso del spam con imágenesEl spam con imágenes vivió su máximo apogeo en 2006 y 2007. Desde octubre de 2006 hasta marzo de 2007, más del 40 por ciento de mensajes de spam contenían imágenes adjuntas. Sin embargo, en verano de 2007 cesaron casi por completo las amenazas de spam con imágenes. Solo se registraron dos breves brotes:

• En otoño de 2008, el volumen de spam con imágenes adjuntasalcanzó el 13,5 por ciento a principios de octubre (datostomados de forma semanal).

• A finales de abril de 2009, el spam con imágenes representabael 13 por ciento del total de spam (datos tomados,nuevamente, de forma semanal).

Desde abril de 2009, el spam con imágenes no superó el 10 por ciento. Se han registrado amenazas de spam con imágenes puntuales, aunque estas representan menos de un 10 por ciento (al tomar los datos de forma semanal).

A pesar de todo, en diciembre de 2013, el spam con imágenes regresó. Según la ilustración 5, el 5 de diciembre, los spammers nos sorprendieron con gran cantidad de ataques. Estos nuevos ataques continuaron hasta el 16 de diciembre, llegando a infestar buzones de correo con imágenes prácticamente a diario. Tras una breve pausa, los spammers volvieron a la carga de forma masiva el 23 de diciembre. Esta ofensiva se mantuvo durante un mes completo hasta el 22 de enero de 2014, con una breve pausa entre el 8 y el 13 de enero.

La ilustración 5 también muestra que un mes más tarde, el 24 de febrero, se reanudaron los ataques de spam con imágenes. Sin embargo, este último brote solo duró tres días. Durante dicho periodo, el volumen de correo solo fue la mitad del registrado en diciembre y enero.

Nuevo ataque:24 Feb

60%

50%

40%

30%

20%

10%

0%

Ilustración 5. Porcentaje de ataques de spam con imágenes, desde el 1 de diciembre de 2013 hasta el 1 de marzo de 2014.

Nuevo ataque:23 dic

Primer ataque:5 dic

Porcentaje de spam con imágenesDesde el 1 de diciembre de 2013 hasta el 1 de marzo de 2014

24 FebDic Dic Dic Dic Dic Dic Ene Ene Ene Ene Ene Ene

12 Informe IBM X-Force Threat Intelligence del segundo trimestre de 2014

La tabla 1 resume algunos de los detalles técnicos analizados durante estos recientes ataques.

Si comparamos los ataques, llegamos a las conclusiones siguientes:• Técnicamente, estas recientes amenazas de spam no utilizan

nuevas tecnologías. La utilización de modificaciones de imágenes e intervalos de tiempo para mantener las URL de spam es una técnica que está un tanto "pasada de moda". No estamos seguros de por qué los spammers usan estas técnicas tan obsoletas; sin embargo, quizás porque han estado inactivos durante cinco años, suponen que los filtros no están preparados para grandes ataques de spam con imágenes.

• Las similitudes existentes entre estos dos tipos de ataquesindica que posiblemente ambos se hayan iniciado con el mismo conjunto de herramientas.

• El spam con imágenes es un problema importante, ya que losspammers pueden transmitir sus mensajes en las imágenes,donde los módulos de análisis de contenido no pueden extraerinformación del contenido de texto. Esto merma lascapacidades de detección de spam de los filtros que usantecnología de detección de texto. Los spammers puedenincluso usar las imágenes para hacer que usuarios accedan aURL que pueden infectar el equipo del usuario mediante unataque de descarga no autorizada (como hemos visto en elpasado). En este contexto, estas nuevas amenazas de spam conimágenes pueden considerarse como un banco de pruebas delos ataques de spam del futuro.

Será interesante analizar si 2014 es el año del regreso del spam con imágenes.

Características

Productos anunciados Productos médicos

Ataque de febrero de 2014

Acciones

Características deimagen

Los productos médicos se anunciaban en las imágenes. Se mostraba una captura de pantalla de texto para anunciar acciones específicas. Con esta amenaza, solo se usaban dos imágenes distintas.

Características de URL

Al hacer clic en las imágenes del mensaje de correo electrónico, se redirigía al destinatario a un sitio web del tipo [...]doctor[...].ru o [...]medic[...].ru. Estas URL no cambiaban tan amenudo.

No se usaba ninguna URL. Los spammers proporcionaban el símbolo de las acciones para hacer que los destinatarios buscaran dicho símbolo para comprar las acciones.

Características de imagen usadas en ambos ataques

Hemos observado algunas diferencias en el modo en que los atacantes usan el spam con imágenes en comparación con las primeras técnicas aplicadas durante el periodo de 2006 a 2007. Antes, los atacantes modificaban las imágenes para evitar los filtros de detección de spam: puesto que muchos filtros de spam usaban un hash de archivo para determinar si un elemento adjunto estaba asociado a actividades de spam, los atacantes creaban una imagen base que pareciese un archivo distinto al incorporar, por ejemplo, modificaciones de color en varios píxeles. En cambio, en los ataques recientes, las imágenes no se modifican y los spammers usan las mismas imágenes en sus ataques.

Texto aleatorio usado en ambos ataques

Debajo de la imagen, los atacantes insertaban gran cantidad de texto aleatorio tomado, en muchos casos, de artículos de Wikipedia. Normalmente, este texto se usaba para confundir los filtros de spam como, por ejemplo, los filtros Bayesian.

Texto aleatorio El texto era difícil de leer porque apenas se distinguía del fondo blanco. Estaba situado justo debajo de la imagen.

El texto se mostraba en el correo electrónico de forma clara. Sin embargo, debajo de la imagen se insertaban líneas vacías para obligar al usuario a desplazarse hacia abajo para ver el texto aleatorio.

Ataques de diciembre de 2013 a enero de 2014

Tabla 1. Detalles técnicos detectados durante los ataques de spam con imágenes realizados de diciembre de 2013 a enero de 2014 comparados con los de febrero de 2014.

IBM Security Systems 13

Tal como se muestra en la ilustración 6, los atacantes usan dominios doctor.ru y medic.ru en estos ataques, lo que plantea la pregunta de si siguen usando el mecanismo de registrar los dominios [...]doctor[...].ru o [...]medic[...].ru. La respuesta es que sí.

Desde principios de diciembre de 2013 hasta finales de enero de 2014, el número de dominios [...]doctor[...].ru o [...]medic[...].ru registrados corresponde con el porcentaje de ataques de spam con imágenes perpetrados. Sin embargo, desde principios de febrero de 2014, los atacantes han usado estos dominios para el envío de spam no basado en imágenes.

Llama especialmente la atención el hecho de que los emisores de spam con imágenes siguen usando estos dominios (a veces durante varias horas o hasta durante más de un día). Esta tendencia se ha mantenido durante los últimos cuatro meses analizados. Este es un periodo demasiado largo en lo que a utilización de URL para ataques de spam se refiere. Esto contrasta con que la mayoría de los spammers usan sus dominios solo durante unas horas o minutos, ya que muchos filtros de spam comprueban las URL usadas en los mensajes de correo y las bloquean si detectan que se usaron previamente para el envío de spam. Puesto que los spammers son propietarios de estos dominios, pueden controlar fácilmente el tiempo durante el cual los usuarios hacen clic en estas URL. Por ello, pese a que el dominio haya estado en uso durante un día o más, siempre hay filtros de spam incapaces de detectar la amenaza o siempre hay usuarios que no usan ningún tipo de filtro.

200180160140120100806040200

50%45%40%35%30%25%20%15%10%5%0%

Ilustración 6. Comparación de dominios doctor.ru y medic.ru con el porcentaje de ataques de spam con imágenes por semana, desde diciembre de 2013 hasta marzo de 2014

Dominios doctor.ru y medic.ru recién registrados Porcentaje de ataques de spam con imágenes

1Dic

8Dic

15Dic

22Dic

29Dic

5 Ene

12Ene

19Ene

26Ene

2Feb

9Feb

16Feb

23Feb

2Mar

9Mar

16Mar

Comparación de dominios doctor.ru y medic.ru recién registrado con porcentaje de ataques de spam con imágenesDesde diciembre de 2013 hsata marzo de 2014, por semana

Dom

inio

s do

ctor

.ru

y m

edic

.ru

reci

én r

egis

trad

os

14 Informe IBM X-Force Threat Intelligence del segundo trimestre de 2014

Los problemas de seguridad pueden ocurrir en cualquier lugar. Descubra cómo puede preparar a su personal de TI para responder ante incidencias de forma remota.

Antes, responder ante las incidencias requería acudir urgentemente a las instalaciones del cliente, cosa que agradaba a los técnicos especialistas, sobre todo si

tenían que ir a instalaciones de clientes que estaban en islas tropicales.

Hoy en día, el paradigma ha cambiado. Debido a los requisitos normativos en el ámbito de los datos personales y a la importancia de los problemas de seguridad, muchas organizaciones necesitan que los expertos respondan de una forma más rápida y eficaz. En determinados estados, las organizaciones están obligadas a notificar a las entidades reguladoras de amenazas que están aún sin confirmar en apenas unos días. Esto ha obligado a los técnicos como, por ejemplo, los miembros del equipo IBM Global Technology Services - Emergency Response Services (ERS), a desarrollar métodos y usar herramientas de discriminación para agilizar la respuesta ante incidencias. De este modo, usan herramientas y métodos que permiten tomar de los sistemas comprometidos artefactos como, por ejemplo, los registros de eventos o de RAM para, a continuación, enviarlos a analistas remotos para que puedan iniciar el análisis del problema cuanto antes.

¿Qué ocurre cuando el sistema de información que parece presentar el problema se encuentra en una zona del mundo que carece de la infraestructura necesaria para ofrecer la respuesta pertinente ante la incidencia? Por ejemplo, ¿qué hacer si no hay suficiente ancho de banda como para transferir a los analistas los artefactos claves de la incidencia (técnica comúnmente usada para la rápida evaluación de los problemas)? Puede incluso darse el caso de que el sistema se encuentre en un país lejano en vías de desarrollo al que resulta complicado acudir y que, además, carece de profesionales de TI cualificados.

Estas son las situaciones a las que se enfrenta el equipo IBM ERS. Ante el creciente número de empresas que expande sus operaciones más allá de los mercados tradicionales, la asistencia remota de incidencias es un servicio que se requiere con mayor frecuencia. Para responder ante incidencias en países remotos o en situaciones de escasa infraestructura, es necesario contar con una planificación única.

Esta sección del informe aborda los cinco principales puntos que se deben tener en cuenta para abordar situaciones de incidencias con sistemas extremadamente remotos. Algunos de los puntos son de carácter técnico, mientras que otros son cuestiones de gestión; aunque todos ellos tienen la misma importancia.

Cinco consideraciones principales cuando la respuesta remota a las incidencias se vuelve extremadamente remota

Ilustración 7. Cinco principales puntos que se deben tener en cuenta para la gestión de incidencias remotas según el equipo

IBM Global Technology Services - Emergency Response Services (ERS)

1. Ancho de bandaLas transferencias de datos pueden verse limitadas debido a conexiones lentas e inestables.2. RAMLas unidades externas pueden no estar disponibles para el almacenamiento de archivos de volcado de la RAM.

3. Correo urgenteDificultades para el envío de datos de diagnóstico o de sistemas con problemas.

4. Horario de trabajoLas diferencias de zona horaria pueden repercutir en las planificaciones del trabajo.

5. Conjuntos de habilidadesLos administradores de sistemas pueden no estar debidamente formados para responder ante las incidencias.

Aspectos que se deben tener en cuenta para la respuesta a incidencias remotas

IBM Security Systems 15

1. El ancho de banda mandaPuesto que no todos los problemas de seguridad tienen lugar en sistemas de información que se encuentran en zonas que disponen de conexiones

de banda ancha como, por ejemplo, centros de datos o países industrializados, los especialistas pueden verse obligados a trabajar con conexiones lentas e inestables. Esta situación puede requerir mayores esfuerzos para resolver las incidencias. Normalmente, cuando el equipo ERS aborda una incidencia de seguridad, los analistas comienzan a trabajar tan pronto como reciben determinados archivos (registros, muestras de software malintencionado, artefactos de la RAM o de otro tipo). Aunque transferir varios gigabytes de datos puede parecer lento, es una operación factible que permite al personal de ERS comenzar a analizar el problema más rápido que con el envío del técnico o de unidades de disco duro.

Cuando el ancho de banda se convierte en un problema, los técnicos se ven obligados a eliminar artefactos del sistema de información de gran tamaño para obtener artefactos de menor tamaño. La eliminación de estos conjuntos de artefactos del sistema de información puede incrementar el tiempo necesario para obtener un diagnóstico, reducir la seguridad del diagnóstico e incrementar el coste general de la respuesta. Las limitaciones de ancho de banda también restringen la posibilidad de jumpbox o sistemas host bastión, un método probado y eficaz para realizar análisis y conectar con sistemas remotos.

¿Qué es un servidor bastión?

Los sistemas host bastión9 son equipos específicos que están totalmente expuestos a los ataques. Dichos equipos se encuentran en la parte pública de la red perimetral sin la protección de cortafuegos ni routers de filtrado. Al estar expuestos, los hosts bastión están configurados para desempeñar un rol específico (como por ejemplo, actuar como servidor proxy), por lo que todos los servicios, protocolos, programas y puertos de red que no son necesarios están desactivados o eliminados. Los hosts bastión también ayudan a controlar el acceso de los intrusos y limitan los métodos usados para realizar ataques.

2. Posibles problemas de acceso a la RAMUno de los artefactos más valiosos para un técnico es sin duda la RAM del sistema comprometido. La RAM de los equipos modernos es el punto donde

más datos de prueba se pueden encontrar. De hecho, hay muy pocos elementos (o quizás ninguno) que resulten más valiosos para este fin. La RAM puede contener todo un tesoro de información con detalles sobre los puertos abiertos, las conexiones de red, los procesos en ejecución, etc.

¿Qué ocurre cuando hay problemas de acceso a la RAM? Según la experiencia del equipo IBM ERS, las incidencias en sistemas extremadamente remotos puede plantear dos retos. Durante varias incidencias con sistemas remotos, el equipo de ERS se ha enfrentado con multitud de problemas a la hora de recopilar datos de la RAM. En primer lugar, el gran tamaño del archivo de la RAM, sobre todo en servidores avanzados, puede ser un problema, llegando incluso a superar los 8 GB tras la compresión. Los problemas de ancho de banda de Internet y de estabilidad en la conexión pueden ralentizar o paralizar la transferencia de archivos de gran tamaño. En segundo lugar, para recopilar los datos de la RAM, es necesario volcar la información a una ubicación externa, como, por ejemplo un dispositivo USB. Los equipos ERS han tenido que abordar numerosas incidencias en las que no pudieron almacenar archivos de volcado por la falta de dispositivos USB. Cuando no hay unidades USB disponibles, probablemente resulte difícil dar con un distribuidor de dispositivos electrónicos (por ejemplo cuando el sistema comprometido se encuentra en una plataforma petrolífera en la costa de Nigeria o en una zona rural en Uganda).

Aunque es posible que no se pueda acceder a todo el archivo de volcado de la RAM, puede que sí sea posible acceder a los datos de la RAM o al menos conseguir que un administrador del sistema acceda a dichos datos. Además, siempre es posible obtener información sobre usuarios conectados, archivos abiertos, tareas programadas, etc., utilizando técnicas más rudimentarias y menos eficaces. Independientemente de si hay problemas de acceso a la RAM o de si el técnico usa técnicas menos eficaces, la organización debe estar preparada para afrontar los retos que plantea la recopilación de datos volátiles.

16 Informe IBM X-Force Threat Intelligence del segundo trimestre de 2014

Las restricciones de ancho de banda y las dificultades para acceder al volcado de la RAM no hacen que las incidencias sean imposibles de abordar. Sin embargo, los equipos técnicos no habituados a trabajar en estas circunstancias deben estar preparados. El desarrollo de métodos y la formación para atajar estos problemas debe ser de obligado cumplimiento para organizaciones cuyos sistemas de información se encuentren en áreas con ancho de banda limitado o en las que no sea posible obtener el volcado de la RAM. De lo contrario, estos retos pueden convertirse en obstáculos infranqueables.

3. Puede que el correo urgente no existaA menudo, los clientes nacionales del equipo IBM ERS recurren al correo urgente para enviar los

sistemas comprometidos o los datos recopilados a los analistas. El envío de imágenes de diagnóstico, datos recopilados de la RAM, archivos de registro o incluso sistemas enteros por correo urgente puede llevar como mínimo unas 12 horas. Además, a la hora de transferir datos entre países —tanto físicamente como a través de Internet— es importante saber si existen normas que impidan la transferencia de datos. Obviamente, el correo urgente puede ser una buena opción si, efectivamente, urge transferir la información.

Pero, ¿qué sucede si los sistemas de información y los datos se encuentran en una zona en la que no existe el correo urgente? Si volvemos al ejemplo de la plataforma petrolífera, puede que no sea logísticamente posible enviar sistemas o archivos desde ubicaciones de este tipo. Además, incluso si el sistema de información se encuentra en países en los que existen servicios como, por ejemplo, UPS o FedEx, a veces ocurre que los envíos de elementos de gran valor (como los equipos informáticos) quedan varios días retenidos en aduanas. Cuando se necesitan respuestas de inmediato y el tiempo es escaso, estos retrasos pueden mermar la agilidad y la eficacia de la respuesta.

4. El horario de trabajo puede afectar a lasplanificacionesNormalmente, durante la gestión de las incidencias, el personal de ERS realiza solicitudes

a los contactos establecidos (como, por ejemplo, los administradores de sistemas) durante el horario laboral conforme evoluciona el análisis del problema. Se trata de un proceso fluido y las solicitudes suelen atenderse con urgencia debido a la gravedad que plantea el problema de seguridad.

Sin embargo, es muy posible que el análisis de problemas de seguridad de organizaciones extremadamente remotas no se desarrolle de este modo. Las diferencias de zona horaria pueden exigir que los recursos de contacto tengan que trabajar varias horas antes o después de su horario laboral local. Esta limitación puede obligar al equipo técnico a ajustar su planificación de trabajo o a realizar solicitudes adicionales. Por lo tanto, los analistas deberán pensar bien qué elementos necesitan para avanzar con el análisis, puesto que en caso de que falten datos, no recibirán respuesta hasta dentro de 24 horas.

IBM Security Systems 17

5. Falta de habilidadesEn general, los técnicos del equipo de ERS, suelen tener la suerte de trabajar con administradores de sistemas altamente cualificados cuando abordan

incidencias de seguridad. En algunos casos, este hecho puede marcar la diferencia entre un problema cuya solución lleva pocos días o, en cambio, semanas.

En la mayoría de incidencias que ha gestionado el equipo de ERS en zonas extremadamente remotas, los contactos o administradores de sistemas a menudo carecen de las habilidades técnicas básicas. Con este tipo de incidencias, los expertos deben ser conscientes de esta limitación y, por lo tanto, asegurarse de que todas las instrucciones, preguntas y comunicaciones son extremadamente específicas, no abiertas a interpretaciones e independientes de los niveles de habilidad.

Una forma de minimizar los problemas que plantean las diferencias de zona horaria y la falta de competencias técnicas

es asegurarse de que la organización disponga de expertos en la gestión de incidencias en varias áreas geográficas. Estos expertos no necesitan ser gurús técnicos. Contar con un administrador de sistemas mínimamente formado con habilidades básicas para abordar incidencias puede ayudar a garantizar una mínima disponibilidad de asistencia de expertos en el lugar en que se produzca la incidencia. Disponer de un experto local con conocimientos básicos en primeras medidas que deben tomarse, protección de datos y métodos de investigación puede marcar la diferencia entre incidencias solucionadas en días o en semanas.

En definitiva, responder ante incidencias en áreas extremadamente remotas es posible; sin embargo el personal debe estar preparado para ajustar sus procedimientos, desarrollar tácticas y trabajar con datos limitados. Comprender las limitaciones y realizar ajustes al inicio de la acción puede ayudar a garantizar el éxito en la respuesta a pesar de los obstáculos imprevistos.

18 Informe IBM X-Force Threat Intelligence del segundo trimestre de 2014

El equipo de investigación y desarrollo IBM X-Force estudia y supervisa las tendencias de amenazas más recientes, como, por ejemplo, las vulnerabilidades,

los ataques activos, los virus, el malware, el spam, los ataques de suplantación de identidad y el contenido web malintencionado. Además de asesorar a los clientes y al público acerca de las amenazas más recientes, IBM X-Force también proporciona contenido de seguridad con el fin de proteger a los clientes de IBM de dichas amenazas.

Colaboración en IBM SecurityIBM Security representa varias marcas que, en conjunto, ofrecen un amplio espectro de servicios de seguridad:

• El equipo de investigación y desarrollo de IBM X-Forcedescubre, analiza, supervisa y registra una amplia gama devulnerabilidades y amenazas de seguridad informática, asícomo las últimas tendencias y métodos que usan los atacantes.Otros grupos de IBM se nutren de estos datos para desarrollartécnicas de protección para nuestros clientes.

• Trusteer8 es una empresa de IBM que ofrece una plataformaholística de prevención contra los delitos cibernéticos yprotege a las organizaciones contra el fraude financiero y losproblemas de seguridad con los datos. Cientos deorganizaciones y decenas de millones de usuarios confían aTrusteer la protección de sus aplicaciones web, equipos ydispositivos móviles frente a amenazas en línea (como, porejemplo, los ataques avanzados de suplantación de identidad omalware). Al contar con un equipo de investigación avanzadodedicado, la inteligencia en tiempo real de la plataformabasada en la nube de Trusteer permite una rápida adaptación alas amenazas emergentes.

• El equipo de seguridad de contenido de IBM X-Force rastreay clasifica la web a partir de los análisis, las deteccionesindependientes y la información de IBM Managed SecurityServices.

• IBM Managed Security Services dirige 10 centros deoperaciones de seguridad que proporcionan experiencia,herramientas y servicios de seguridad administrada a clientesde todo el mundo, las 24 horas del día, los 7 días de la semana.Esta división se encarga de supervisar los problemas deseguridad relacionados con los sistemas de extremos, losservidores (incluidos los servidores web), las aplicaciones y lainfraestructura de red general. Los expertos de seguridadrealizan seguimientos de los problemas, los ataques y lasincidencias de miles de clientes.

• IBM Professional Security Services ofrece serviciosempresariales de asesoramiento, diseño e implementación quepermiten crear estrategias de seguridad inteligentes, así comosoluciones eficaces de seguridad de información.

• La plataforma IBM QRadar® Security Intelligence Platformofrece una solución integrada de inteligencia de seguridad ygestión de eventos (SIEM), administración de registros,administración de configuración, evaluación devulnerabilidades y detección de anomalías. Esta plataformaproporciona un panel unificado y perspectivas en tiempo realde la seguridad y los riesgos de cumplimiento que afecta a losindividuos, los datos, las aplicaciones y las infraestructuras.

• IBM Security AppScan ayuda a las organizaciones a evaluar laseguridad de aplicaciones web y móviles, así como a mejorar laadministración del programa de seguridad de las aplicacionesy a garantizar el cumplimiento de las normativas con laidentificación de vulnerabilidades y la generación de informescon recomendaciones de corrección inteligentes que facilitanla solución de los problemas. El servicio IBM HostedApplication Security Management es una solución basada enla nube que permite realizar pruebas dinámicas de aplicacionesweb mediante AppScan tanto en entornos de preproduccióncomo de producción.

Información sobre X-ForceLas amenazas avanzadas están por todas partes. Minimice el riesgo con las perspectivas de expertos de IBM.

IBM Security Systems 19

Colaborador Cargo

Andrew Cranke Consultor de seguridad de aplicaciones sénior, IBM Hosted Application Security Management

Anik Campeau Consultor de seguridad de aplicaciones, IBM Hosted Application Security Management

Diana Kelley Estrategia de seguridad de aplicaciones, IBM Security AppScan

Dr. Jens Thamm Administrador de bases de datos, IBM X-Force Content Security

John Adams Analista de incidencias sénior, IBM Global Technology Services - Emergency Response Services

Leslie Horacek Administrador, IBM X-Force Threat Response

Marc Noske Administrador de bases de datos, IBM X-Force Content Security

Mark Wallis Desarrollador de información sénior, IBM Security Systems

Pamela Cobb Administrador de segmentos de mercado global, IBM X-Force and Security Intelligence

Ralf Iffert Administrador, IBM X-Force Content Security

Rob Lelewski Director de Compromiso, IBM Global Technology Services - Emergency Response Services

Robert Freeman Administrador, IBM X-Force Advanced Research

Thomas Millar Analista de incidencias sénior, IBM Global Technology Services - Emergency Response Services

El informe IBM X-Force Threat Intelligence Quarterly es fruto de la colaboración dedicada de todos los recursos de IBM. Por ello, no queremos dejar pasar la ocasión sin agradecer a las personas siguientes la atención y participación prestadas para la publicación de este informe.

Para obtener más información sobre IBM X-Force, visite: ibm.com/security/xforce/

Colaboradores Más información

© Copyright IBM Corporation 2014

IBM Corporation Software Group Route 100 Somers, Nueva York 10589

Producido en los Estados Unidos de América Junio de 2014

IBM, el logotipo de IBM, ibm.com, AppScan, Global Technology Services, Qradar y X-Force son marcas comerciales de International Business Machines Corp., registradas en muchas jurisdicciones de todo el mundo. El resto de nombres de servicios y productos pueden ser marcas comerciales de IBM o de otras empresas. Encontrará una lista actualizada de las marcas registradas de IBM en la Web, en el apartado sobre información de Copyright y marcas registradas en ibm.com/legal/copytrade.shtml

Microsoft y Windows son marcas comerciales de Microsoft Corporation en los Estados Unidos, en otros países o en ambos.

Este documento está actualizado a la fecha inicial de publicación e IBM puede modificarlo en cualquier momento. Las ofertas no están disponibles en todos los países en los que opera IBM.

LA INFORMACIÓN DE ESTE DOCUMENTO SE PROPORCIONA “TAL CUAL” SIN NINGÚN TIPO DE GARANTÍA, TANTO EXPRESA COMO IMPLÍCITA DE COMERCIABILIDAD, IDONEIDAD PARA UN FIN DETERMINADO Y SIN NINGÚN TIPO DE GARANTÍA O CONDICIÓN DE NO INFRACCIÓN. Los productos de IBM se garantizan según los términos y condiciones de los acuerdos en virtud de los cuales se proporcionan.

El cliente es responsable del cumplimiento de las leyes y normativas aplicables. IBM no presta ningún servicio de asesoramiento legal ni garantiza que la utilización de sus servicios o productos por parte del cliente esté conforme a ninguna ley o normativa. Las declaraciones relacionadas con proyectos futuros de IBM e intenciones están sujetas a cambios o cancelación sin previo aviso, por lo que solo pueden considerarse como objetivos.

Declaración de buenas prácticas de seguridad: La seguridad de sistemas de TI abarca la protección de los sistemas y la información a través de la prevención, la detección y la respuesta ante situaciones de acceso inadecuado a la información tanto desde dentro como desde fuera de su empresa. El acceso inadecuado puede dar lugar a la alteración de la información, a su destrucción o puede incluso dar lugar a daños u usos inapropiados de los sistemas, incluido el ataque a otros sistemas. Por lo tanto, ningún sistema o producto de TI debe considerarse como completamente seguro. Asimismo, ningún producto o medida de seguridad puede considerarse como completamente eficaz en la protección frente al acceso inadecuado. Los productos y sistemas de IBM están diseñados para formar parte de un enfoque integral que implica procedimientos operativos adicionales y puede requerir la eficacia de otros sistemas, productos o servicios. IBM no garantiza que los sistemas y productos sean inmunes a conductas malintencionadas o ilegales de otras partes.

1 Chris Poulin, “What to Do to Protect against Heartbleed OpenSSL Vulnerability,” IBM Security Intelligence Blog, 10 de abril de 2014. http://securityintelligence.com/heartbleed-openssl-vulnerability-what-to-do-protect/

2 Roee Hay, “New Vulnerabilities in Firefrox for Android: Overtaking Firefox Profiles,” IBM Security Intelligence Blog, 26 de marzo de 2014. http://securityintelligence.com/vulnerabilities-firefox-android-overtaking-firefox-profiles/

3 Roee Hay, “A New Vulnerability in the Android Framework: Fragment Injection,” IBM Security Intelligence Blog, 10 de diciembre de 2013. http://securityintelligence.com/new-vulnerability-android-framework-fragment-injection/

4 “OWASP Top 10 for 2013,” OWASP, 12 de junio de 2013. https://www.owasp.org/index.php/Top10#OWASP_Top_10_for_2013

5 “StatCounter Global Stats: Top 7 Desktop, Tablet and Console OSs from Oct 2013 to Mar 2014,” StatCounter, fecha de acceso del 17 de abril de 2014. http://gs.statcounter.com/#os-ww-monthly-201310-201403-bar

6 Enterprise Customers: Support for Windows XP has ended,” Microsoft, abril de 2014. https://www.microsoft.com/en-us/windows/enterprise/end-of-support.aspx

7 Jose Pagliery, “95% of bank ATMs face end of security support,” CNNMoney, 4 de marzo de 2014. http://money.cnn.com/2014/03/04/technology/security/atm-windows-xp/?iid=EL

8 Trusteer, Ltd. was acquired by IBM in September of 2013.

9 Kurt Dillard, “Intrusion Detection FAQ: What is a bastion host?” The SANS Institute, fecha de acceso del 13 de mayo de 2014. http://www.sans.org/security-resources/idfaq/bastion.php

WGL03050-ESES-00

Por favor, recicle.