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/?autor=0 
http://ejemplo.com/?autor=1  
http://ejemplo.com/?autor=2  


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

http://ejemplo.com/autor/usuario0/
http://ejemplo.com/autor/usuario1/
http://ejemplo.com/autor/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