Actualizaciones en Materia de Seguridad de la Información de la Circular Básica Jurídica de la SFC

De acuerdo con la legislación colombiana, la Superintendencia Financiera de Colombia (en adelante SFC) somete a inspección, vigilancia y control a las entidades que realizan la inversión o manejo de recursos recibidos o captados del público. Esta definición no incluye a las entidades que se dedican a prestar servicios en la red asociados al comercio electrónico para almacenar, procesar y/o transmitir el pago correspondiente a operaciones de venta en línea comúnmente conocidas como pasarelas de pago. Sin embargo, teniendo en cuenta que una de las responsabilidades de la SFC es la de preservar la confianza pública de los ciudadanos y la estabilidad del sistema financiero, ésta ha decidido regular a las pasarelas a través de la relación contractual que se genera cuando los establecimientos de crédito y los administradores de sistemas de pago de bajo valor (aquellos que tienen lugar entre consumidores, empresas y el gobierno, generalmente por bajas cuantías y de menor urgencia, dado que no hay un número único que defina la frontera entre un pago individual de alto o uno de bajo valor, su categorización termina siendo basada en la naturaleza de las operaciones, los instrumentos de pago utilizados, los canales de pago por los cuales se efectúan las correspondientes transferencias de dinero y lo crítico que puede ser la pronta oportunidad del pago) establecen relaciones comerciales con las pasarelas de pago para las actividades relacionadas con la prestación de servicios de aplicación de comercio electrónico para almacenar, procesar y/o transmitir el pago correspondiente a operaciones de venta en línea.

La vinculación a la vigilancia que realizará la SFC de las pasarelas de pago se da en la Circular Externa 008, publicada el 5 de junio de 2018, donde se incorporan las nuevas responsabilidades para las pasarelas de pago, formalizando algunas que ya estaban heredando de manera contractual como son el cumplimiento de las regulaciones relacionadas con la prevención de lavado de activos y financiación del terrorismo (SARLAFT).

Otras responsabilidades adicionadas están asociadas al cumplimiento de la Ley 1581 de 2012 -de Protección de Datos Personales- y la Ley 1266 de 2008 -Ley de Habeas Data- que, por la definición del alcance de estas leyes, estos establecimientos ya deberían estar cumpliendo.

Una obligación nueva, que es una buena práctica de la industria, es la de dar información al consumidor financiero sobre la manera como se realiza el procedimiento de pago, que consiste en una alineación perfecta con los estándares de la industria en materia de seguridad en relación con los programas de concientización que se deben mantener, de manera continua, para asegurar que el eslabón más débil en la cadena de seguridad, los usuarios, realice sus procesos de la manera adecuada.

Dentro de las nuevas responsabilidades sobre las pasarelas de pago, nace una adición que es la adopción de un estándar de la industria de medios de pago con tarjeta que no estaba dentro de las obligaciones de las entidades vigiladas. El estándar en mención es el PCI DSS (que está mal relacionado en la primera mención a este -denominándolo PCI DDS- pero indicado de manera correcta en la segunda mención).

Para entender el alcance de esta nueva responsabilidad debemos conocer un poco sobre este estándar. PCI DSS, acrónimo del término en inglés Payment Card Industry Data Security Standard, fue desarrollado por 5 de las grandes franquicias de pago (Visa, MasterCard, Discover, American Express, JCB) con el objetivo de proteger los datos de tarjeta en los procesos, tecnologías y personas relacionadas con el almacenamiento, procesamiento y transporte de dichos datos.

PCI DSS define un conjunto de controles orientados a preservar la confidencialidad de los datos de tarjeta, los controles definidos pasan desde políticas y procedimientos, pasando por el establecimiento de mecanismos técnicos de monitoreo y control hasta llegar a algunos detalles asociados a versiones específicas de algoritmos.

La cadena de obligación de cumplimiento habitualmente venía dada por la relación contractual que existe entre las diferentes partes que componen el ambiente de medios de pago, entre estos componentes tenemos: las franquicias, los adquirientes, los comercios y los proveedores de servicio. Las pasarelas de pago suelen ubicarse dentro del rango de proveedores de servicio, aunque algunas realizan funciones adicionales.

Aunque esta obligación de cumplimiento del estándar está definida en los diferentes contratos, la aplicación de la misma en muchos casos no se da por falta de control de los adquirientes sobre sus proveedores de servicio y se hace de manera irregular.

El proceso de validación de cumplimiento está diseñado para que algunas empresas que han pasado estándares rigurosos de validación,  formación continua y aseguramiento de calidad, sean acreditados para realizar dichas verificaciones de cumplimiento, estas organizaciones deben seleccionar especialistas teniendo en cuenta su experiencia y certificaciones en temas relacionados con seguridad de la información, para luego hacerlos formar y certificar por parte del PCI SSC (Payment Card Industry Standards Security Council), una vez certificados obtienen el título de QSA (Qualified Security Assessor) y se debe hacer un proceso anual de re-entrenamiento y re-certificación para el mantenimiento de dicha acreditación.

Cerrando el paréntesis que se abre para la explicación sobre el estándar, debemos analizar la implicación de este requisito. La imposición del mismo nace de la necesidad de brindar seguridad en un canal que anteriormente no estaba regulado por el estado y que es un vector de ataque de las organizaciones criminales ya que da acceso a grandes cantidades de datos de tarjetas, lo que hace de este sector un objetivo bastante atractivo.

El estándar está definido para ser cumplido sobre ambientes que manejen tarjetas franquiciadas; cuando la SFC lo pone como obligación para las pasarelas de pago amplía su alcance a tarjetas no franquiciadas, obligando a muchas pasarelas que centran su servicio en tarjetas no franquiciadas a cumplir con dicho estándar, y de paso asegurando que la información del consumidor financiero colombiano tiene unos mecanismos mínimos de protección.

Al asumir el estándar PCI DSS, la SFC deja en manos del PCI SSC la seguridad de los medios de pago del consumidor financiero colombiano, esto tiene dos puntos de vista: el malo, una regulación colombiana que depende de un ente que no es colombiano para definir los mecanismos de control para proteger la información de los residentes en Colombia; el bueno, este ente se mantiene a la vanguardia en temas de seguridad de la información y está alineado con las buenas prácticas de la industria.

La validación de cumplimiento del estándar es delegada por la SFC en los QSA (Qualified Security Assessor) que son las empresas calificadas para verificar la correcta implantación de los controles de la norma en un ambiente, lo cual asegura una vigilancia continua de la alineación de las empresas con el estándar, sin embargo, no hace referencia a quien debe realizar el monitoreo de que dichas validaciones de cumplimiento sean realizadas.

Otro elemento importante incluido es el requerimiento de mantener vigente la certificación de manera anual, esto busca garantizar que los controles de seguridad son mantenidos por las organizaciones como parte de su operación diaria brindando un ambiente seguro para las operaciones realizadas a través de estas pasarelas.

Fuera de los cambios relacionados con las pasarelas de pago encontramos que esta circular, además de actualizar algunos términos, hacer salvedades necesarias y aclarar la redacción en algunos puntos, extiende el alcance de otros numerales o sub-numerales de la norma, entre estos tenemos:
  • Los canales e instrumentos de prestación de servicios financieros que estaba limitando el ámbito de aplicación a tarjetas de crédito y móviles, dando alcance a las tarjetas débito y a cualquier dispositivo electrónico que sirva para realizar operaciones.
  • Esta ampliación permite asegurar que todos los tipos de tarjetas y nuevos medios de pago, como por ejemplo carteras electrónicas son tenidas en cuenta dentro de los controles que se deben tener en cuenta en el momento de usar alguno de los canales o instrumentos de prestación de servicios financieros asegurando que las entidades financieras no dejen de cumplir sus obligaciones por cuenta de una falta de especificidad de la norma.
  • El análisis periódico de vulnerabilidades, que anteriormente era obligatorio para los establecimientos de crédito y los administradores de pago de bajo valor, ha extendido su alcance a las sociedades especializadas en depósitos y pagos electrónicos y las entidades vigiladas que permitan la ejecución de órdenes electrónicas para la transferencia de fondos, la compra, venta o transferencia de títulos valores y la emisión de pólizas de seguros, por sistemas de acceso remoto para clientes, Internet o dispositivos móviles.
  • La ampliación de este alcance busca que todos los canales o entidades que los usuarios del sistema financiero usan para movimientos financieros estén monitoreados de acuerdo con las buenas prácticas de la industria relacionadas con el monitoreo del estado de seguridad técnica de los canales usados para este tipo de transacciones.
  • El envío de información confidencial cifrada por correo electrónico ahora se amplía a canales como mensajería instantánea o cualquier otra modalidad de comunicación electrónica.
  • Este cambio busca proteger la información confidencial de los usuarios del sistema financiero, sin embargo, aunque es loable el intento al ampliar los canales por los que es transmitida la información, no busca corregir una mala práctica de la industria que es la de usar un dato de carácter público (el número de documento de identificación) como la parte secreta en el proceso de cifrado para proteger dicha información. Esperemos que en una próxima iteración de las mejoras a esta circular se incluya el término cifrado fuerte y se incluya que este cifrado se realice mediante el uso de una contraseña seleccionada por el usuario.

Otros cambios importantes realizados en la regulación:
  • Un cambio que se ve muy pequeño y que puede pasar inadvertido, pero es interesante es el de la modificación de los tiempos de retención de las imágenes de video que se baja de 8 a 6 meses y se limita a las operaciones monetarias que antes estaba circunscrita para los servicios financieros. Este control que tiene un impacto significativo en el costo de la operación de cada oficina y cajero automático donde se prestan servicios financieros, desde una perspectiva de riesgo permite a las entidades centrar los esfuerzos en los puntos más sensibles de las operaciones financieras que son las operaciones monetarias, la reducción de tiempos de almacenamiento pueden obedecer a un análisis de riesgos realizado por la SFC, a las estadísticas de reclamaciones realizadas por los usuarios en las entidades financieras, y a la cantidad de información que pueda brindar una grabación de video en operaciones no monetarias, esta reducción de tiempos de almacenamiento se mantiene dentro de los estándares de la industria.
  • El punto donde la reducción de tiempos de almacenamiento se percibe fuera de buenas prácticas de la industria es el del almacenamiento de los registros de información enviada y recibida en los centros de atención telefónica, este control en la industria habitualmente maneja tiempos de retención de 1 año y en esta versión de la regulación se ha bajado a 6 meses, si tenemos en cuenta que mediante estos canales se hacen cambios en los productos, incluyendo adquisiciones y cancelaciones de los mismos, este plazo podría considerarse como insuficiente desde la perspectiva de trazabilidad en el ciclo de vida de los productos.
  • Un cambio que resulta peligroso desde el punto de vista de seguridad es la eliminación de la restricción de almacenamiento de datos sensibles o confidenciales en los móviles sin incluir un control para asegurar que cuando se almacene se haga en condiciones de seguridad. Este cambio, que desde el punto de vista de usabilidad es beneficioso para el usuario, debería estar acompañado de controles técnicos que permitan salvaguardar los mecanismos de accesos a las cuentas de los usuarios.
En resumen, la SFC, cumpliendo con su mandato de proteger a los usuarios del sistema financiero colombiano, sigue llenando el espacio en temas de seguridad donde las entidades financieras deberían haber tomado la iniciativa en muchos aspectos y que no han hecho su tarea de manera satisfactoria.
Queda pendiente hacer algunos ajustes a esta regulación para que las entidades hagan su deber de protección de la información de sus clientes de manera correcta ya que se aprovechan vacíos gramaticales para dar soluciones incompletas a temas fundamentales de seguridad.

Esta actualización de la regulación en temas de seguridad es un acierto de la SFC ya que trae novedades importantes en ampliación de alcances e inclusión de estándares de la industria que son buenas prácticas del medio de seguridad y que buscan proteger al usuario financiero.

Autor: Javier Roberto Amaya Madrid.  - CISM, PCI QSA, P2PE QSA, PCI 3DS, PCI PCIP, MCPS, ISO 27001 LA
Consultor en Seguridad

Cómo proteger Wordpress (3/3): Seguridad por ocultación

Seguridad por ocultación en Wordpress
¿Cómo saber si un plugin está instalado en una web Wordpress?
Wordpress instala los plugins en el directorio web wp-content/plugins/
Una estructura habitual de encontrarnos por tanto en nuestro servidor web es:

/var/www/html/wordpress/wp-content/plugins/plugin_name_1
/var/www/html/wordpress/wp-content/plugins/plugin_name_2
/var/www/html/wordpress/wp-content/plugins/plugin_name_3

Y en el código html de la página se traducirá en:

http://www.dominio.com/wp-content/plugins/plugin_name_1
http://www.dominio.com/wp-content/plugins/plugin_name_2
http://www.dominio.com/wp-content/plugins/plugin_name_3

Una manera de identificar los plugins que tiene instalados una web hecha en Wordpress es revisar el código HTML de la web, en búsqueda de la cadena wp-content/plugins.

De esta manera podríamos ver sólo algunos plugins, digamos los que están en ejecución en ese momento. Pero podemos ver todos los instalados de otra manera. Esto es, podemos hacer peticiones, por diccionario, a dichas urls:

http://www.dominio.com/wp-content/plugins/*

Un diccionario de plugins para tomar como ejemplo sería éste.
Por ejemplo, si hacemos una petición como la siguiente:

curl -I http://www.dominio.com/wp-content/plugins/plugin_name 

y esta petición nos devolviera un 200 (OK) como retorno HTTP, tendríamos la confirmación de que dicho plugin está instalado. Si por el contrario recibiéramos un 404 (Not Found) tendríamos descartada su presencia.

¿Cómo saber la versión el plugin instalado?
Por consenso y estandarización, todos los desarrolladores de plugins han de incluir el fichero readme.txt. En dicho fichero se hace una descripción del plugin: su desarrollador, la versión, una descripción del mismo, o instrucción de instalación entre otras.

Si lanzamos una petición a dicho fichero:
http://www.dominio.com/wp-content/plugins/plugin_name/readme.txt

Podremos consultar en concreto la versión del plugin y, por extensión, las vulnerabilidades conocidas de dicha versión del plugin.

Este escenario conlleva un riesgo directo a la seguridad de cualquier website Wordpress puesto que anuncia públicamente sus componentes y versiones, y facilita enormemente el trabajo a un atacante.

¿Cómo ocultar los plugins de Wordpress instalados?
En el primer capítulo veíamos cómo denegar el acceso a ficheros sensibles mediante .htaccess.
Sin embargo no podríamos evitar la enumeración de plugins.

Aquí entra en escena el concepto de seguridad por ocultación. Lo que vamos a hacer es ponérselo un poquito más difícil a un posible atacante.

Sabemos que ante peticiones del tipo

curl -I http://www.dominio.com/wp-content/plugins/plugin_name

si el plugin plugin_name está instalado devolverá un http return code 200, y si no lo está será un 404. Asumiendo que no podremos evitar el 200, intentaremos evitar el 404. O dicho de otra manera, vamos a devolver siempre (sea cual sea el plugin consultado) un 200 para que el atacante reciba que tenemos tal cantidad de plugins instalados que no pueda discernir con sencillez cuáles son ciertos y cuáles no.

Para ello sólo bastaría crear una estructura de carpetas sobre

/var/www/html/wordpress/wp-content/plugins/

con los nombres de los plugins de nuestro diccionario. Ni más ni menos que 70.000 plugins pueden confundir lo suficiente a nuestro atacante. Cuando empiece el ataque probando nombres de plugins siempre recibirá un 200 suplantando la existencia real y no podrá saber por este método cuáles son ciertos y cuáles falsos.

¿Cómo ocultar la versión de los plugins realmente instalados?
Al tener bloqueada la respuesta a ficheros readme.txt en el fichero .htaccess como vimos en el capítulo 1, tampoco podrá saber sus versiones, ni de los falsos ni de los verdaderos.

¿Cómo saber si una plantilla está instalada en una web Wordpress?
Wordpress instala las plantillas en el directorio web wp-content/themes/

Saber la versión de la plantilla instalada es muy sencillo. Revisando el código HTML de una web Wordpress fácilmente encontraremos la ruta que delata el nombre de la plantilla en uso:

http://www.dominio.com/wp-content/themes/theme_name_1

¿Cómo evitar la ruta de instalación wp-content/themes/ para evitar la identificación de la plantilla?
Se puede hacer, requiriendo por parte del usuario un conocimiento alto acerca de Wordpress ya que requeriría modificar el código del CMS. Sin embargo existe un riesgo adicional. Muchos desarrolladores de plantillas y plugins utilizan enlaces mencionando explícitamente la carpeta wp-content en sus códigos, y en caso de instalarlos encontraríamos enlaces rotos puesto que nuestra ruta ya cambió de nombre, con lo que no funcionarían. En realidad la tarea de administración se puede complicar considerablemente. Es por ello que esta medida de seguridad requiere ser sopesada seriamente ya que puede no compensar lo suficiente.

¿Cómo saber la versión de la plantilla instalada?
Siguiendo el ejemplo anterior, una petición a:

http://www.dominio.com/wp-content/themes/theme_name/readme.txt 

nos devolverá el fichero del desarrollador donde se revela la versión de la plantilla.

Como vimos en el primer capítulo, mediante el bloqueo configurado en .htaccess del fichero readme.txt, el atacante no podrá acceder a dicho fichero y por tanto consultar la versión.

Aquí ponemos fin a esta serie de tres artículos:
  • En el primero vimos una serie de recomendaciones generales a alto nivel.
  • En el segundo entramos en algunas configuraciones más técnicas limitando el acceso a algunos recursos críticos.
  • En éste hemos aplicado el concepto de seguridad por ocultación en una instalación de Wordpress.
Conclusiones
Wordpress no es un gestor de contenidos más inseguro que otros. Quizás su principal virtud es a la vez su gran debilidad. Wordpress tiene una gran comunidad de desarrolladores generando contenido (plantillas y plugins), lo cual convierte su comunidad en una fuente muy rica y variada en componentes.

Sin embargo esto también supone su principal vulnerabilidad, ya que es frecuente encontrar plantillas y sobre todo plugins desarrollados con fallos graves de seguridad. Por tanto deberemos tener especial cuidado a la hora de integrar componentes nuevos en nuestra web.

Esperamos haber ayudado a mejorar la seguridad de las aplicaciones web de nuestros lectores. Sabemos que no existe la protección total, pero estamos convencidos de que las recomendaciones recopiladas en esta serie de artículos, constituyen un salto cualitativo en la seguridad de cualquier website hecho Wordpress.

Esperamos que sean de su agrado.



Autor: Gonzalo Sánchez Delgado
Dpto. Auditoría

Cómo proteger Wordpress (2/3): Configuraciones de seguridad con .HTACCESS

Continuando el primer artículo de esta serie de recomendaciones sobre cómo proteger Wordpress, abordaremos esta vez una serie de recomendaciones para configurar en nuestro servidor web privado.

Nos apoyaremos en este caso en el fichero .htaccess, un archivo de configuración muy conocido en entornos web php y que nos permite aplicar políticas de acceso a directorios y ficheros. No es objeto de este artículo explicar cómo funciona htaccess, partimos de la base de que ya existe ese conocimiento y partiremos de ahí para hacer nuestras recomendaciones.

Desactivar la navegación de directorios
Wordpress trae habilitada por defecto la navegación de directorios en varias partes de su estructura. Por citar sólo algunos ejemplos podríamos encontrar:

http://192.168.10.3/wp-content/uploads/ 
http://192.168.10.3/wp-includes/ 
http://192.168.10.3/wp-content/plugins/plugin-name/

Esto permite a un atacante navegar por los directorios pudiendo tener acceso a ficheros ocultos.

Para deshabilitar esta característica añadiremos la línea:

Options All -Indexes

Bloquear la enumeración de usuarios
Es posible identificar los usuarios de una instalación de Wordpress de una manera bastante sencilla. Las peticiones:

http://ejemplo.com/?author=0 
http://ejemplo.com/?author=1  
http://ejemplo.com/?author=2  


automáticamente redirigen a unas url con el enlace permanente donde se muestra el username real de quien escribió:

http://ejemplo.com/author/usuario0/
http://ejemplo.com/author/usuario1/
http://ejemplo.com/author/usuario2/


Incluso añadiendo el nombre en el título la página:


Para evitar esta práctica podemos redirigir al atacante a una url externa cada vez que la petición coincida con el patrón mencionado anteriormente. Podemos añadir las siguientes líneas:

<IfModule mod_rewrite.c>
    RewriteCond %{QUERY_STRING} ^author=([0-9]*) [NC]
    RewriteRule .* http://example.com/? [L,R=302]
</IfModule>

Siendo example.com el sitio al que enviar la redirección.

Bloquear ficheros readme.html readme.txt y similares
Por consenso y estandarización, todos los desarrolladores de plugins y plantillas han de incluir el fichero readme.txt en su paquete de instalación. En dicho fichero se hace una descripción del plugin o plantilla: su desarrollador, la versión, una descripción del mismo, o instrucción de instalación entre otras.

De la misma forma, en cada versión nueva que se lanza, Wordpress añade el fichero readme.html  donde igualmente se muestra la versión instalada.

Éstos son solo dos ejemplos, pero existen más ficheros con información de configuración, y para evitar estas filtraciones de seguridad vamos a bloquear el acceso a todos estos ficheros:

RewriteRule (?:readme|license|changelog|-config|-
sample)\.(?:php|md|txt|html?) - [R=404,NC,L]


Proteger el área de administración restringiendo por IP
En el primer artículo  de esta serie, comentábamos la necesidad de proteger el portal de login de Wordpress contra ataques de fuerza bruta. En dicho artículo recomendábamos el uso del algún plugin de seguridad que permitiera el bloqueo de usuarios por intentos fallidos al introducir contraseña.

En este sentido gracias al fichero .htaccess vamos a añadir una capa de seguridad antes del propio Wordpress. En los casos en los que la administración de la página siempre se haga desde unas localizaciones físicas con IP estática, se puede restringir el acceso para que exclusivamente se pueda hacer desde esas IPs:

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName "WordPress Admin Access Control"
AuthType Basic
<LIMIT GET>
order deny,allow
deny from all
# oficina
allow from xx.xx.xx.xxx
# VPN
allow from zz.zz.zz.zz
</LIMIT>

Proteger el acceso al área de administración con usuario y contraseña
En los casos en los que no se pueda restringir por IP o en los que se quiera añadir una capa adicional, podemos configurar un acceso por usuario y contraseña al portal del login.


Tendremos que crear un fichero con las credenciales:

htpasswd -c /path/.htpasswd usuario

Donde /path es la ruta donde queremos dejar el fichero, que debe estar fuera del esquema de carpetas del servidor web. usuario es el username de la credencial. El comando nos pedirá por duplicado la contraseña.

A continuación creamos un fichero .htaccess en el directorio /wp-admin/ con las siguientes líneas:

AuthName "Panel de admin"
AuthUserFile /path/.htpasswd
AuthGroupFile /dev/null
AuthType basic
require valid-user
Donde /path es la ruta donde se dejó el fichero .htpasswd.

Bloquear tráfico XMLRPC
El protocolo XMLRPC es un protocolo de comunicación via HTTP de datos en formato XML. Este protocolo se utiliza como si se tratase de una API para conectar el Wordpress con aplicaciones de terceros. Esta comunicación se hace a través del fichero:

http://ejemplo.com/xmlrpc.php

Este protocolo tiene el riesgo de sufrir ataques de denegación de servicio, así que en caso de no utilizarse es recomendable bloquear su acceso:

<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

Redirigir todas las páginas de error del servidor web a una página estándar

Habitualmente los atacantes consiguen inferir bastante información de las aplicaciones web con los mensajes de error. Por ejemplo, si se hace una petición a un recurso y éste no existe devolverá un error 404 (not found) con su página correspondiente, pero si el recurso existe pero no se tiene permisos sobre él obtendremos un 403 (Forbidden) y otra página de error. Aquí ya se puede deducir información.



Por este motivo una buena práctica es capturar estas respuestas y devolver una web genérica en su lugar para que el atacante no reciba los mensajes a primera vista:

ErrorDocument 403 /error.html
ErrorDocument 404 /error.html
ErrorDocument 500 /error.html

En el siguiente artículo, abordaremos algunas recomendaciones de seguridad bajo el concepto de Seguridad por ocultación.


Autor: Gonzalo Sánchez Delgado
Dpto. Auditoría

Cómo proteger Wordpress (1/3): Recomendaciones Generales

Wordpress continúa siendo la referencia absoluta en lo que respecta a gestores de contenido para páginas web un año más. Se estima que una de cada tres páginas web en internet es un Wordpress, lo que supone una cifra descomunal. Dada su gran cuota de utilización lleva varios años en el punto de mira de los cibercriminales.

Muchos de nuestros clientes también utilizan Wordpress y pensamos que sería una buena idea ofrecer una serie de recomendaciones con respecto a su configuración. Hemos redactado una serie de tres artículos en la que comenzaremos con aspectos generales a alto nivel, hasta ir profundizando más a nivel técnico en algunos puntos.

En cualquier caso, estos tres artículos pretenden no ser un manual de instalación y configuración estricto y ceñido, sino por el contrario, nos gustaría presentar estos artículos como una guía de buenas prácticas y recomendaciones flexibles a cualquier uso. En un mundo tan cambiante como el de la ciberseguridad, nada ofrece una garantía total ante los cibercriminales, pero esperamos ayudar a mejorar la seguridad de nuestros clientes y de cualquier usuario de Wordpress.

RECOMENDACIONES GENERALES
Los CDN:
Los CDN son una potente medida de seguridad frente a varios tipos de ataques. Sin duda, su principal protección es contra ataques de DDoS (denegación de servicio distribuida). Al ser capaces de distribuir dinámicamente tráfico a lo largo de sus grandes redes, consiguen dispersar de manera efectiva grandes volúmenes de tráfico sin afectar al rendimiento de una aplicación web.

Hemos conocido múltiples casos de clientes y organizaciones que son víctimas de ataques de DDoS por parte de su competencia comercial, por sabotajes corporativos o hacktivismo. En estos casos, contratar un CDN es una medida efectiva para paliar los efectos de estos ataques.

Sin embargo los CDN también ofrecen servicios de WAF (Firewall de Aplicación Web) e IDS (Sistemas de Prevención de Intrusiones) de tal forma que entran a proteger ataques contra la lógica de la aplicación, protegiendo contra hackeos e intrusiones en los sistemas del cliente. Como siempre, la protección de un CDN es evadible en algunas ocasiones, pero sin duda representa una protección eficiente.

No debemos olvidar que los CDN por último también cumplen notablemente una función de optimización de la web ya que tienen un rendimiento excelente en la descarga de la web a los clientes.

Wordpress suele integrarse perfectamente con los CDN, hasta el punto de que la mayoría ofrecen plugins oficiales para instalar de tal forma que el propio Wordpress y el CDN se integren a la perfección.

Los ejemplos son múltiples pero podríamos mencionar aquí a Akamai, CloudFlare, Sucuri o los mismos CDN de Amazon o Google.

VPS siempre mejor que un Hosting compartido       
El riesgo de alojar una web Wordpress o de cualquier otro tipo, en un hosting compartido, es que la web será alojada en el mismo servidor que cientos de otras aplicaciones web. Por este motivo la seguridad de nuestra web ya no depende exclusivamente de ella misma, sino también de todas las demás. Una vulnerabilidad que ponga en jaque el servidor web nos afectará a nosotros también.

Por este motivo siempre es más recomendable contratar un servidor dedicado (VPS) donde la seguridad corra por nuestra cuenta y tengamos la confianza de depender en exclusiva de nosotros mismos. Es cierto que podrían existir otros vectores por parte del proveedor de servicios de hosting, sin embargo, las posibilidades de sufrir una ataque por esa vía serían mucho más remotas que en el caso de alojarnos en un hosting compartido.

Plugins: menos es más
Los plugins son la principal amenaza en las páginas Wordpress. Al estar desarrollados por terceros, habitualmente no han sido desarrollados teniendo en cuenta la seguridad y acumulan montones de vulnerabilidades importantes. Es recomendable instalar la menor cantidad de ellos y siempre que no usemos alguno, eliminarlo del Wordpress.

Así mismo, mantener actualizados la plantilla en uso y todos los plugins nos protegerá de vulnerabilidades en versiones previas.

Proteger servicios en la misma IP que nuestra web
Suponiendo que disponemos nuestro propio servidor privado, no es recomendable alojar servicios adicionales como FTP, SSH o cualquier otro, en la misma IP pública del servidor web ya que estamos facilitando el trabajo a un cibercriminal. Al conocer nuestro dominio, conocería por tanto la IP de nuestro servidor y, por tanto, descubriría dichos servicios. Estaríamos aumentando la probabilidad de sufrir un ataque ya que no sólo tendríamos que proteger la web, sino también tendríamos que proteger los servicios publicados.

De ser posible, dichos servicios deben ser ofrecidos a través de VPN puesto que suelen utilizarse para actualizar contenidos en la web o administrar el servidor. Por tanto, no tienen por qué estar accesibles para cualquier persona en internet.

Convertir Wordpress en una web estática
Una página estática es aquella donde sus peticiones no manejan parámetros. Simplemente se solicitan y se descargan archivos con el código html.

Las virtudes de Wordpress como gestor de contenidos son sus infinitas posibilidades de personalización de los contenidos en la web. Sin embargo, en la mayoría de casos no se hacen cambios como demasiada asiduidad. Además, si la web tiene como funcionalidad exclusiva la de mostrar contenidos (imaginemos la página web de una empresa donde sólo se anuncian sus servicios y una página con información de contacto) sin ningún elemento dinámico como ecommerce, foros, etc, podemos tomar la decisión de convertirla en una web estática.

Si éste es el caso, una recomendación puede ser la de tener dos entornos. Un entorno de desarrollo donde realizamos todos los cambios y actualizaciones en el Wordpress original, y otro entorno de producción donde lo que subimos es una copia estática de la web.

Proteger Wordpress es una tarea ardua ya que son múltiples los elementos a revisar: el propio motor de Wordpress, la plantilla instalada, los plugins de terceros… De esta manera, podríamos quitarnos un gran número de vulnerabilidades de raíz.

Plugins de Seguridad

El mercado de los plugins de terceros de Wordpress es infinito. Con respecto a la seguridad son múltiples los plugins que existen y no será objeto de este artículo compararlos. Lo que sí es importante tener en cuenta son las funcionalidades que nos ofrecen y que deben cubrir obligatoriamente:

Función de firewall de aplicación web (WAF)
El plugin elegido debe poder actuar como firewall web en nuestra aplicación. Esto es imprescindible en especial si no tenemos un CDN contratado. Esta función nos protegerá de posibles vulnerabilidades en el código de Wordpress, de la plantilla o de cualquiera de los múltiples plugins instalados.

Protección contra ataques de fuerza bruta en el login
Debemos tener una protección contra ataques de fuerza bruta en la página de login de Wordpress. Así cuando un usuario ingrese varias veces mal la contraseña, automáticamente quedará bloqueado por un tiempo determinado o indefinidamente. Muchos plugins de seguridad de Wordpress traen integrada esta funcionalidad. De no ser el caso deberíamos contar con ella.

Existen algunos plugins que cambian la url de login de Wordpress para complicar la tarea de los atacantes que quieren forzar nuestra web. Esta medida sin embargo no creemos que sea recomendable. Siempre preferimos y recomendamos instalar la menor cantidad de plugins de terceros posible para reducir el número de vulnerabilidades. Además modificar la estructura original de Wordpress con frecuencia acaba complicando la administración en futuras actualizaciones y subidas de versión.

Backup
La recomendación eterna y más evidente. Necesitamos tener un backup de nuestro Wordpress, tanto de los ficheros y carpetas de nuestro web server como de la base de datos. En caso de tener algún problema, es imprescindible tener una copia de seguridad para restaurar.

En el siguiente artículo abordaremos unas configuraciones técnicas.


Autor: Gonzalo Sánchez Delgado
Dpto. Auditoría

Vicente Aguilera miembro del Jurado de los Trofeos de la Seguridad TIC


Un año más, Vicente Aguilera forma parte del selecto grupo que compone el Jurado de los XII Trofeos de la Seguridad TIC, que estudia y analiza las distintas candidaturas que se presentan a estos premios.

Este certamen internacional se encuentra organizado por la revista Red Seguridad (revista independiente especializada en Seguridad de la Información), y se premia a las personas o entidades – del sector público y privado - que se hagan acreedoras de ello.
Los trofeos son los siguientes:
  • T1- Trofeo al producto/servicio o sistema de seguridad más innovador
  • T2- Trofeo a la empresa SegTIC del año
  • T3- Trofeo a la institución u organismo público en materia de seguridad TIC
  • T4- Trofeo a la trayectoria profesional pública o privada en seguridad TIC
  • T5- Trofeo a la capacitación, divulgación, concienciación o formación en seguridad TIC
  • T6- Trofeo al centro educativo SegTIC del año
  • TE- Trofeo extraordinario del jurado
La entrega de premios se realizará el 19 de junio en COEM (Auditorio). C/ Mauricio Legendre, 38 (Madrid).

Más información:
http://www.redseguridad.com/content/download/69076/554294/file/bases%20trofeos%20red%202018-min.pdf

Publicada la versión 3.2.1 de PCI DSS


Recientemente, el PCI SSC ha publicado la versión 3.2.1 de su estándar de seguridad PCI DSS.

Dicha actualización menor comporta pocos cambios respeto a la versión 3.2, siendo los más destacados los siguientes:
  • Requerimientos 2.2.3, 2.3 y 4.1: Se elimina la referencia al apéndice A2, relativo a la migración de SSL/versiones preliminares de TLS, ya que la fecha límite fijada para dicha migración ya se ha alcanzado.
  • Requerimientos 3.5.1, 6.4.6, 8.3.1, 10.8, 10.8.1, 11.3.4.1, 12.4.1, 12.11 y 12.11.1: Se eliminan los comentarios relativos a la fecha límite para el cumplimiento de los mismos (1 de febrero de 2018), ya que dicha fecha ya se ha superado.
  • Anexo A2: A partir de ahora, solo se permitirá la utilización de SSL/versiones preliminares de TLS en terminales de punto de venta en canales de venda físicos (POS-POI), que no sean susceptibles de ser afectados por exploits reconocidos.

Hasta el 1 de enero de 2019, pueden usarse para las evaluaciones PCI DSS tanto la versión 3.2 como la versión 3.2.1. A partir de ese día, la versión 3.2 será retirada, siendo obligatorio el uso de PCI DSS 3.2.1.

Para finalizar, deben tenerse en cuenta los siguientes aspectos, relativos a los cambios en PCI DSS que están por llegar:
  • El próximo cambio mayor del estándar PCI DSS se prevé para el año 2020.
  • Nuevas versiones de los documentos SAQ serán publicadas en junio de este año, que reflejarán los cambios introducidos en la versión 3.2.1 de PCI DSS. Además, se incluirá el requerimiento 6.2 en el SAQ A, cosa que obligará a los comercios a instalar los parches de seguridad críticos en un plazo máximo de 30 días des de su publicación.

Bibliografía
https://blog.pcisecuritystandards.org/pci-dss-now-and-looking-ahead
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2-1.pdf
https://www.pcisecuritystandards.org/documents/PCI_DSS_Summary_of_Changes_3-2-1.pdf


Autor:
Guillem Fàbregas Margenats
CISSP, CISSP Instructor, CISA, CISM, CRISC, PCI QSA, PCIP, ISO 27001 L.A.
Dpto. Consultoría Barcelona


Crónica Mundo Hacker Day 2018


Otro año más acudimos a MundoHackerDay, este año se ha enfocado principalmente a la era digital en la que vivimos. En este gran evento, nos ha mostrado que cada vez estamos conectados a un mundo en el cual hay una serie de amenazas que afectan tanto a empresas como a usuarios. Estas amenazas entre otras pueden ser robo de identidad, fuga de datos hasta las famosas estafas con criptomonedas.

Para dar pie a este evento, Víctor Aznar, (GlobbTV), hizo una pequeña introducción y posteriormente dio paso a Antonio Ramos que nos deleitó con su charla “The Upside Down World (Stranger Things)”. En la cual, nos habló de cómo está afectando la evolución tecnológica y los riesgos que con ello conllevan. Nos comentaba que realmente la tecnología en muchos casos nos está ayudando, pero … a su vez también nos está ocasionando problemas (falta de seguridad, riesgos, desempleo, etc... Vamos lo que viene siendo el mundo al revés, queremos tenerlo todo, pero a su vez lo estamos complicando cada vez más.

Para continuar, contamos con la presencia de Carlos Gómez (Aruba), con su charla “WPA3: Seguridad Móvil de última generación”, nos habló de cómo habían impactado las vulnerabilidades en anteriores protocolos por ejemplo en WPA 2 como krack y la evolución del protocolo wifi el cual el nuevo modelo que se va a implantar en este 2018 es WPA 3. El cual nos mencionaba que se produce una mejora de autenticación y cifrado. Que va a contar con un cifrado de 192 bits y cuenta con una implementación del protocolo Dragonfly (Autenticación Simultánea de Iguales) que mejora la seguridad en el momento del handshake, que es cuando se intercambian la clave de la red, que los ataques por diccionario ya no van a ser posibles, la mejora para dificultar los posibles ataques Mitm mediante el uso de datos cifrados de manera individual, etc.

Posteriormente seguimos con una charla de la mesa redonda, “La nueva era de la seguridad ¿Hacia un “Black Mirror” cada vez más real?”, en ella pudimos contar con la presencia de los siguientes componentes: Dani Creus (Kaspersky), Josep Albors (ESET), Conrado Crespo (Panda Security), Antonio Navas (Viewnext), Melchor Sanz (HP), Alberto Ruiz Rodas (Sophos), Daniel de Blas (Modera). En este debate se habló sobre el impacto de los ataques, que cada vez son más sofisticados. Con el paso del tiempo contamos cada vez de más avances en la tecnología, como por ejemplo la inteligencia artificial, tecnología biométrica, los aparatos que conectamos a Internet y este impacto afecta tanto a usuarios como empresas, ya sean tanto amenazas como la privacidad de los mismos.

La siguiente ponencia la realizó Jorge Hurtado de S21sec, “Operaciones de Seguridad guiadas por Inteligencia: ¿qué es la pirámide del dolor?”, En ella hizo referencia al servicio de respuesta ante incidentes, la lucha constante contra este tipo de técnicas de grupos organizados, describiendo el tipo de técnicas sus prácticas, procesos y estrategias concretas de detección y respuesta contra este tipo de amenazas persistentes avanzadas.

Continuamos con una mesa redonda, la cual contamos con: Silvia Barrera [IN]Seguridad Informática, Tamara Hueso (Deloitte), Rosa Díaz (Panda Security), María José Talavera (IBERIA VMware),Albora Trimiño (Cybersecurity Operator IT Risk Fraud and Security), Miriam Martínez (Miembro de HoneySec), Pilar Vila (Computer forensic expert), María José (ESET) Moderadora Desireé Rodriguez en la charla “Hack Woman by ESET”.  En ella, hacían referencia a la falta de mujeres en este sector de la ciberseguridad. Principalmente en España nos comentaban que estamos por debajo de la media en este sector, ya no en este sector de la ciberseguridad sino en el sector TIC.

Seguimos con Vicente Pérez “Seguridad en entornos x-cloud”, se centró en la seguridad de los datos y la privacidad que nos ofrecen dichos entornos. Nos mostraba las distintas herramientas, soluciones de seguridad, los tipos de estrategias, ya que todo es bastante complejo y para todo ello es muy importante construir un buen plan de seguridad.

Después de todas las charlas anteriores, realizamos un breve descanso, en el cual se nos invitó a todos los asistentes a café, refrescos y algo de picar patrocinado por Panda.

Para seguir, ya una vez todos más activos después del café, seguimos con la charla de Jose Pino “KEYNOTE: "Trape: the phishing evolution", nos mostró como muchas veces podemos estar expuestos a Internet, utilizando la técnica de Phising. Pudimos ver su herramienta en acción (Trape), que es una herramienta de investigación OSINT, la cual permite rastrear personas, obtener información confidencial, ejecutar ataques de ingeniería social inteligentes... sin que el propio usuario se entere.

La siguiente charla fue “Cuando la amenaza está dentro: detección y respuesta temprana frente a ataques con Aruba Introspect” por Artur Gradoli, hizo referencia al tipo de ataques y cómo podemos nosotros mejorar la detección y respuesta con una herramienta llamada Aruba Intropect, la cual aplica una seguridad basada en aprendizaje automático.

El siguiente turno fue para David Conde con “Ay, ay, ay … dándoles a los malos donde más les duele!”, hizo mención a los ciberataques y como poder tener una respuesta ante incidentes y la lucha contra algunos de los grupos organizados más sofisticados que actúan en el ámbito internacional y las amenazas avanzadas persistentes.

Proseguimos con la mesa Redonda con “las Comunidades de Hacking” en la que contamos con la compañía de : María José Montes  (Hacking Solidario),  Raúl Fuentes (TomatinaCON), Adrián Ramírez (Sec/Admin), Ángel Pablo Avilés (Por Una Red Mas Segura) , David Moya (Eastmadh4ck), Carlos García (Qurtuba Security Congress y Hack&Beers), Esteban (FaqIN ), Dauksis, Igor Lukic(Hackron), Juan Antonio (HoneyCON),  Pilar Vila (María Pita DefCon), Juan Carlos Gutierrez Florez (MundoHacker - HHS), Moderador:Tatiana Gutiérrez Marqués, INCIBE, se habló sobre las fakenews como impactac en la socidad que vivimos y la importancia de la concienciación en la ciberseguridad.

Para continuar seguimos con Gabriel Lazo Canazas, “de Digital Molotov “, nos describió algunas de las tendencias en los servicios del mercado negro del cibercrimen y como con una serie de datos pueden ser usados para generar dinero.

Seguimos con Carlos Loureiro y su ponencia “BlackThunder: Oax y phising en telegram”, nos enseñaba el uso de Telegram para realizar campañas de Oax y Phising contra objetivos específicos.

La siguiente charla fue de Óscar Atienza González, “Evolución de los Sistemas SIEM 4.0”, nos habló de la evolución de los mismos, de cómo han ido avanzando y adaptándose a lo que se está demandando en los entornos de la Seguridad de la Información.

Continuamos con Abel Valero, “Análisis de malware altamente ofuscado”, nos describió diferentes tipos de malwares con sus ejemplos y el tipo de técnicas utilizadas en cada uno, describiendo así el tipo de ofuscación y como había sido generado.

La siguiente charla fue de Josep Albors, “Amenazas dirigidas a criptomonedas”, nos mostró los vectores de ataques que se están utilizando por parte de los ciberdelicuentes. Con los cuales es posible el minado de criptomonedas y ocultar la trazabilidad de las mismas en el mercado.

Seguimos con Yago Hansen, “Indetectable Wi-Fi Rogue AP”, nos describió una técnica utilizada para crear un punto de acceso wifi el cual es capaz de evadir los firewall, DPS, Ids haciéndolo indetectable con el fin de exfiltrar información.

El siguiente ponente fue Dani Creus “Amenazas Digitales Avanzadas: Perspectiva desde las trincheras”, nos habló sobre la clasificación de amenazas que hay y nos mostró algunos ejemplos de malware en cajeros automáticos.

Proseguimos con Simón Roses “Tácticas Recon”, nos mostró algunas de las técnicas de reconocimiento más modernas que se utilizan en la actualidad, las cuales se utilizan mucho sobre todo en las fases de pentesting.

Seguimos con Enrique Serrano “Hacking Scripting Toolbox”, nos habló del uso de la librería de Scapy y realizo ejemplos prácticos de ataques como por ejemplo Sniffer Wifi, Fake Ap, robo de credenciales, encuestas.

Continuamos con Alberto Ruiz, “Más allá del Machine Learning: Deep Learning”, nos describía que es el Deep Learning, que es el Machine Learning y como se utiliza en la actualidad.

Seguimos con Alberto Ruiz “DenyEvery1: Defending Active Directory against the hunt for privileged users”, exhibió algunas de las técnicas que se utilizan a la hora de atacar o realizar un pentest para escalar privilegios de administrador en un entorno de Active Directory.

La siguiente charla la dio Manuel Huerta “Asegurar el Ciberiesgo: Pólizas Ciber, desde las grandes multinacionales a las pymes, ¿de qué protegen?”, en su charla hizo mención a que es necesario proteger los sistemas de las empresas ante posibles riesgos cibernéticos, saber cuál es el estado de las posibles vulnerabilidades que podamos tener en nuestra empresa, entre otras y tener buenos métodos de actuaciones dirigidas a la prevención y contención de riesgos.

 Seguimos con Pedro Candel con “Where is Wally?, nos enseñó con distintos ejemplos el uso de los dispositivos IMSI Catchers y mediante dispositivos de bajo coste como un SDR, permitiría obtener información de geolocalización remota de terminales móviles mediante técnicas de consulta a las celdas y diferentes comprobaciones al HLR/VLR del SS7 o incluso la interceptación dentro del rango de cobertura del terminal a localizar.

Llegando ya casi al final contamos con David Marugan y Fernando Corrales “Comunicaciones secretas Y Redes “Stay-Behind”: El proyecto “Harpoon”, en la charla se describieron y se mostraron algunos ejemplos de las redes clandestinas Stay-Behind, el funcionamiento a nivel técnico y de COMSEC (Seguridad en Comunicaciones) de las redes secretas de espionaje, usando el equipo transceptor FS-5000 “HARPOON”, usado desde finales de la Guerra Fría para comunicaciones cifradas.

Y ya para finalizar, terminamos con Deepak Daswani “Operación eBikini”, que nos mostraba los posibles peligros que hay a nuestro alrededor, como son algunas apps de gimnasios y la explotación de servicios de las mismas.

También y no menos importante mencionar al grupo de CTF Academy, cuyos miembros enseñaron a futuros expertos en seguridad como poder resolver y enfrentarse a los retos hacking.

Autor:
Héctor Berrocal Vidal
CEH, MCP, CCNA, ITIL
Dpto. Auditoría

Las noticias más relevantes del mes en Medios de Pago

Resumimos algunas de las noticias más relevantes relacionadas con la Seguridad en Medios de Pago compiladas de diferentes fuentes, medios y recursos confiables, con el fin de mantener a nuestros seguidores al día en lo que respecta al ámbito de la seguridad de medios de pago.

Australia's Commonwealth Bank pierde datos de 20 millones de cuentas
Para un país como Australia que tiene 26 millones de habitantes, la potencial pérdida de información del banco Australia's Commonwealth de 19.8 millones de registros en un par de cintas magnéticas podría catalogarse como desastrosa, sin embargo hasta el momento esta información no parece haber sido usada de manera maliciosa. La implementación de unos pocos controles de PCI DSS habría evitado un evento de este tipo.
Fuente: Bank Info Security

Actualización al lineamiento de computación en la nube de PCI SSC
En abril se liberó una revisión del suplemento informativo de lineamientos para computación en la nube. Esta actualización pretende ayudar a entender la responsabilidad compartida para proteger los datos entre todas las partes involucradas y cómo mitigar los riesgos potenciales asociados al uso de la computación en la nube.
Fuente: PCI SSC

Plazo límite para migración a TLS
El 30 de junio de 2018 es el plazo límite para aquellos que aun usan SSL o TLS 1.0 como mecanismo para protección de las comunicaciones. A partir de esta fecha se deberá haber migrado a versiones recientes de TLS en todos los sistemas del ambiente de tarjetahabiente. Solo aquellos POS POI que han sido verificados como no susceptibles a las explotaciones conocidas podrán seguir usando estos protocolos. Algunos recursos han sido publicados por el PCI SSC para aquellos que deben hacer la migración.
Fuente: PCI SSC

Atlanta gastó 2.6 millones de dólares para recuperarse de una crisis de ransomware con perdidas de 52 mil dólares
La municipalidad de la ciudad de Atlanta ha gastado más de 2.6 millones de dólares en los esfuerzos de emergencia para responder el ataque del ramsomware SamSam, el cual pedía un rescate de 50.000 dólares en bicoins por cada estación infectada, no hay información de si se intentó pagar este rescate pero el sitio web de los atacantes que debía recibir la información fue dado de baja. La ciudad ha tenido que establecer 8 contratos para cubrir las necesidades de personal adicional, labores forenses, expertos en infraestructura de la nube, comunicaciones, manejo de crisis, entre otros.
Fuente: Wired

Grupo de hacking detrás de brechas de seguridad en Saks Fifth Avenue
El grupo de tiendas por departamentos de Saks Fith Avenue reveló una brecha en sus tiendas Saks Off 5th y Lord & Taylor, con un impacto sobre 5 millones de tarjetas débito y crédito de sus clientes, este mismo grupo ha estado recuperándose los últimos años de un ataque a otros negocios del grupo (Omni Hotels & Resorts, Trump Hotels, Jason’s Deli, Whole Foods, Chipotle). Estos ataques vienen de un grupo organizado llamado Fin7. Este grupo de habla rusa, generalmente trabaja en horas hábiles y ha desarrollado sus propias herramientas de aplicaciones maliciosas y estilos de ataque que les permite evadir la detección de herramientas antivirus y a las autoridades.
Fuente: Wired

Yahoo multado por permanecer en silencio acerca de la brecha en Mega
La brecha del 2014 que tuvo Yahoo le sigue acarreando multas, esta última está relacionada con la obligación que tienen las empresas de notificar a tiempo las brechas (y no dos años después). Esta brecha que fue detectada por el equipo de seguridad unos días después de que ocurrió y notificada al equipo directivo y al departamento legal, fue revelada por la empresa a las autoridades y al público dos años después de que ocurrió.
Fuente: Naked security

Orbitz revela exposición de 880.000 tarjetas de pago a causa de una brecha de seguridad
La compañía reveló recientemente que uno de sus sitios viejos fue comprometido exponiendo información de las personas que hacen compras en línea, esta brecha expuso cerca de 880,000 registros de tarjetas de crédito junto con información personal como nombre, dirección, fecha de nacimiento, teléfono, dirección de correo electrónico y género. Este tipo de brechas muestran la necesidad de asegurar todas las plataformas de la organización sin dejar de lado las viejas o las que se van a reemplazar por su complejidad para asegurarlas.
Fuente: The hacker news

Datos expuestos de miles de clientes de Delta Air Lines y Sears Holding Corp
Delta Airlines reveló que fue víctima de un brecha donde se pueden haber expuesto miles de datos de pago de sus clientes, esta brecha ocurrió en el proveedor de software [24]7, que igualmente pudo afectar a otros clientes como Sears Holding
Fuente: Certsi

La AEPD centrará sus planes de inspección en los sectores de la salud, financiero y de telecomunicaciones
La AEPD, a través de su directora Mar España, ha reiterado que no habrá moratorias para la aplicación del RGPD uqe debe iniciar su aplicación a partir del 25 de mayo. Seto será tangible con los planes de inspección definidos que iniciarán por los sectores más sensibles: salud, instituciones financieras y telecomunicaciones.
Fuente: Noticias jurídicas

Sin tarjeta requerida: Ataques "Black Box" a cajeros automáticos llegan a Europa
Los incidentes que han venido ocurriendo en diversas partes del mundo sobre los ATMs, se están moviendo a Europa, estos incidentes están asociados a un ataque llamado Black Box que implica el compromiso de un puerto USB expuesto.
Fuente: Bank Info Security

NIST ha liberado un borrador de revisión del estándar 800-57 parte 2, relacionado con el manejo de llaves.
Fuente: NIST

NIST publicó la versión 1.1 del marco de trabajo de ciberseguridad.
Después de varias revisiones el marco de trabajo de ciberseguridad de NIST ha llegado a la versión 1.1, esta nueva versión incluye algunas actualizaciones en el manejo de autenticación e identidad, auto evaluación del riesgo, gestión de la ciber seguridad en la cadena de suministros, revelaciones de vulnerabilidades.
Fuente: NIST

Actualización de Lineamientos del PCI SSC para computación en la nube
El PCI SSC ha publicado una actualización de la guía que apoya la implementación de servicios en la nube para organizaciones que deban cumplir con los requerimientos de la norma PCI DSS.
Fuentes: PCI SSC

Revisión menor de norma PCI DSS
El próximo mes el PCI SSC publicará una revisión menor del estándar PCI DSS que tendrá como número la 3.2.1, esta revisión removerá las fechas que ya han pasado en algunos requerimientos, se actualizará el anexo A2 para reflejar el hecho de que únicamente los POS POI podrán hacer uso de SSL y TLS 1.0 hasta el 30 de junio de 2018.
Fuente: Blog PCI SSC

Infiltración al sitio web del banco BGFI
El 12 de abril el pirata informático "Venganza" de quince años se infiltró en el banco comercial BGFI. En un primer ingreso el pirata modificó la página de acceso administrativo para demostrar que tuvo acceso al sitio, cuatro días más tarde después de que el banco había reportado la corrección, modificó nuevamente la página de acceso al banco.
Fuente: ZatazMag

Desarticulada red de distribución de malware
La red de distribución de aplicaciones maliciosas “ElTest” que operaba desde el 2011 desviando 2 millones de usuarios de sitios legales contenido maliciosos, ha sido (al memos temporalmente) deshabilitada por un grupo de investigadores de seguridad.
Fuente: Bank Info Security

Hackers hallan nueva técnica para evadir detección.
Un grupo de investigadores de seguridad ha detectado una nueva técnica usada por aplicaciones maliciosas para evadir las técnicas de detección, esta técnica llamada "Early Bird" permite que el código malicioso sea inyectado en una etapa temprana del inicio del hilo del código de ejecución evitando que las aplicaciones de detección los detecten. Esta técnica ya ha sido encontrada en tres ataques sofisticados.
Fuente: Seguridad y Firewall

Reporte Trustwave Global Security 2018
El reporte de seguridad global de Trustwave ha sido publicado, algunos puntos que se pueden destacar en este reporte: el crimen organizado ahora está detrás del 50% de las brechas, los ataques ransomware se han doblado, el DDoS, el phishing  y ataques de comando y control se han convertido en una amenaza prominente, el error humano sigue contribuyendo en la mayoría de las brechas. El correo electrónico sigue siendo uno de los principales vectores de distribución, Las compañías tienen tres veces más ataques por ingeniería social que ataques técnicos.
Fuente: Trustwave