Crónica de la Conferencia: New Security Encryption Paradigms dentro del #MWC'16 Barcelona

La semana pasada en Barcelona se celebró, un año más el evento más importante de telefonía Móvil, el Mobile World Congress, y entre tanta presentación de nuevos dispositivos, también se hizo un hueco a la seguridad con la Conferencia New Security Encryption Paradigms.

MOBILE 360
La conferencia se inició con la presentación de Ingrid van Engelshoven, vicealcalde de La Haya quien habló de la necesidad de profesionalizar la gestión de la seguridad mediante la creación de estándares mundiales que la normalicen. Puso como ejemplo de amenaza el ataque que sufrió en 2013 en el que prácticamente se quedó el país sin internet. Cabe recordar que dicho ataque fue llevado a cabo por 3 personas dos de ellas menores. Ingrid invitó a los asistentes a asistir el próximo 10-11 de Mayo 2016 en el Hotel Hilton de La Haya a la conferencia Mobile 360 focalizada en Privacidad y Seguridad.

Presentación de Ingrid van Engelshoven

NEW SECURITY
Raj Samani, VP & CTO Intel Security EMEA habló a continuación acerca de los modelos de seguridad y de cómo la seguridad pasa a ser una facility siendo la confianza en la marca y la empresa el valor a asegurar de cara al futuro. Puso como ejemplo cómo los dispositivos móviles recogen datos de forma automática datos que pueden ser explotados por hackers para establecer patrones de comportamiento como ubicaciones o actividades. Finalmente estableció como riesgo los dispositivos SCADA los cuales regulan el consumo doméstico de electricidad/agua/etc…  son vulnerables a ataques por su arquitectura o imposibilidad de actualización. Raj mostró su preocupación acerca de cómo proteger dispositivos a los cuales no se tiene acceso (refiriéndose a los SCADA) y de la aparición de amenazas en dicha área.

SECURITY IOT
La conferencia finalizó con una mesa de debate mantenida por Ciaran Bradley, CTO, Adaptive Mobile Jason Porter, VP, Security Solutions, AT&T y David Kleidermacher CSO, BlackBerry.

Debatieron acerca de la protección y de la facilidad de generar certificados personales para interconectarse a los dispositivos con seguridad habilitando la IOT algo que es un hecho según su punto de vista.

Resaltar un comentario de Jason Porter el cual declaró “La seguridad empieza con una gestión de Riesgos” constatando la necesidad de disponer de mecanismos universales para realizar una correcta identificación y posterior gestión de los riesgos así como la creación (de acuerdo a lo mencionado por Ingrid) de estándares de seguridad a nivel internacional (ahora son a nivel de país).


Autor: Carlos Ortiz de Zevallos - BSI L.A., Scrum Manager, MCP, ITILF, ITIL Service Management
Departamento Consultoría

Lighttpd Hardening Guide v1.0b

Lighttpd es un servidor web diseñado para ser rápido, seguro, flexible, y fiel a los estándares. Está optimizado para entornos donde la velocidad es muy importante, consumiendo menos CPU y memoria RAM que otros servidores web como por ejemplo Apache.

Una de las grandes diferencias de Apache con el resto de servidores webs más recientes es la manera en la que maneja la información, mientras Apache realiza las peticiones de manera sincrónica, Lighttpd y también NGINX realizan estas operaciones de manera asincrónica permitiendo en definitiva gestionar la información de una manera más eficiente.

Si bien es cierto que Apache cuenta con muchos más plugins y mucha más documentación disponible al alcance de todos en internet que Lighttpd, en cuestión de rendimiento Apache sigue quedando un poco atrás, independientemente de que hoy en día sea el más usado.

A la hora de configurar un servidor web es muy importante ser lo más estricto, dentro de lo posible, para intentar prevenir cualquier intento de ataque que pudiera producirse. Como bien todos sabemos esta no es la solución, pero en numerosas ocasiones es evidente que puede entorpecer bastante la tarea de cualquier atacante si este está bien configurado.

Configuración Lighttpd
Por defecto el fichero de configuración de Lighttpd se puede encontrar en la siguiente ubicación.


Grupos/Usuarios
Es importante que el Servidor Web corra con su usuario y su grupo con los privilegios estrictamente mínimos y necesarios para ello. A continuación se incluyen las directivas para definir el usuario y los grupos. Por defecto en este tipo de configuraciones es "lighttpd", también es importante asignar unos permisos y grupos bien definidos a nuestro directorio Web así como dar permisos.


Listado de Directorios
Lo más recomendable es denegar el listado de directorios en toda la raíz del Servidor Web. Podemos hacerlo con la siguiente directiva.


Server Banner
A la hora de determinar que cabecera de servidor usaremos podemos barajar las siguientes opciones como son ocultar la versión o suplantar la cabecera por la de otro Servidor Web que no tengamos instalados. Obviamente la opción menos aconsejable es la de anunciar realmente el Servidor Web que estamos usando, en este caso Lighttpd.

Una posible desventaja la hora de suplantar la cabecera es que herramientas automatizada, escáneres de vulnerabilidades o cualquier otro tipo de herramientas que identifiquen nuestro servidor web por medio de estas cabeceras lanzaran ataques para ese servidor Web anunciado, por tanto la mejor opción siempre será no mostrar información de ningún tipo.

Por ejemplo, si se define la cabecera como Unknow numerosos escáneres de vulnerabilidades Web entre ellos Acunetix WVS mostraran que la cabecera esta falseada.

Podemos definir un Banner para nuestro Servidor Web usando la siguiente directiva.

 

Symlink
Es recomendable deshabilitar cualquier funcionalidad que no vayamos a utilizar, si no vamos a usar el seguimiento de symlink en Lighttpd es recomendable deshabilitarlo mediante la siguiente directiva.

 

Not Found Handler
En numerosas ocasiones nuestro sitios pueden ser escaneados por distintos crawlers que a través de fuerza bruta de directorios y analizando los códigos de respuesta HTTP pueden definir un árbol del directorio del Sitio Web.

Ya que la mayoría de las herramientas están basadas en el análisis de códigos de respuesta para definir si un directorio existe o no, por tanto vamos a redirigir cualquier directorio o fichero no encontrado a nuestro index, de manera que cualquier respuesta la dará como existente, y que para un atacante sea imposible mediante esta técnica listar nuestros directorios y ficheros.


Sin embargo hay otros tipos de herramientas como por ejemplo OWASP DirBuster que cuando comprueban estos comportamientos de respuesta en el servidor, intentan generar otros patrones alternativos para definir la existencia de estos ficheros y directorios. Estas se basan en el tamaño del contenido para definir si el directorio existe o no cuando no se puede determinar a través del código de respuesta HTTP.

Para protegernos ante estas técnicas lo que haremos será implementar en nuestro index un sistema que genere un comentario HTML en el código. De manera que cada solicitud genere un tamaño distinto de respuesta y como consecuente la herramienta generará un alto volumen de falsos positivos imposibilitando a un atacante listar nuestros directorios.

MultiRange Requests
Las peticiones multi-rango son peticiones de uno o más sub-rangos de un archivo. Éstas son útiles para la reanudación de descargas interrumpidas y para traer pequeños fragmentos de ficheros de gran tamaño. Si no vamos a permitir la descarga de ficheros es recomendable deshabilitar este tipo de peticiones.

Si vamos a permitir visualizar ficheros PDF’s mediante el plugin de Adobe Acrobat es recomendable deshabilitar las peticiones multi-rango para este tipo de ficheros ya que puede provocar una denegación de servicio en el plugin si este tipo de peticiones están activadas.


Alive Requests
Es posible definir cuantas conexiones pueden permanecer vivas hasta que se cierra la conexión, el valor por defecto es de 16, 0 es ilimitado, aunque podemos redefinir esto con la siguiente directiva.


Para definir cuantos segundos pueden pasar hasta que una conexión pasa de abierta a estar libre, el valor por defecto son 5 segundos.


Max Request Size
Si nuestro Servidor Web no va aceptar subidas de ficheros ni tampoco vamos a necesitar realizar peticiones de gran tamaño, podemos limitar el tamaño máximo de una petición, el valor por defecto es ilimitado.


 

Traffic Shaping
Se puede limitar el volumen del tráfico por servidor o por conexión de manera que se distribuyan de una manera más estable los recursos del servidor, las directivas están expresadas en kilobytes por segundo.


HTTP Methods
Mediante la siguiente directiva definiremos los métodos HTTP que nuestro Servidor Web aceptará, la directiva usada es por lista blanca, es decir que cualquier método HTTP que no esté incluido no se interpretará, devolviendo un error 403 Forbidden.


Deny File/Extensions
A la hora de denegar extensiones o nombres de ficheros es importante entender por qué estos pueden suponer un riesgo en el momento de explotar un sistema y de qué manera nos pueden proteger ante un ataque. A continuación se incluye una lista de extensiones básicas y nombres de ficheros que sería recomendable denegar el acceso y también una breve descripción de por qué sería aconsejable denegar esta extensión o nombre de fichero.

Extensión/Fichero Descripción
bak
bck
backup
back
Suele ser una extensión comúnmente usada a la hora de realizar una copia de seguridad de un fichero en el servidor local.
ini Posiblemente no queramos mostrar ningún tipo de fichero de configuración expuesto en nuestro servidor por tanto no es una mala idea denegar este tipo.
git En numerosas ocasiones los desarrolladores suben ficheros a entornos que están en desarrollo directamente desde GitHub y estos expuestos en la raíz del servidor ficheros relacionados con el repositorio.
sql
sql.tar
sql.tar.gz
sql.zip
Si algún administrador deja expuesto algún fichero de copia de seguridad de SQL no sería lo más apropiado que este fuese accesible para la descarga. Por tanto denegar este tipo de archivos siempre será una buena opción.
swp
swo
Este tipo de fichero es una extensión asociada a SWAP podría contener algún tipo de información de un fichero que se editó previamente.
save Esta extensión es usada por la utilidad de Unix nano, por ejemplo mientras se edita un fichero a través de SSH, si la conexión cae, el fichero que se estaba modificando en cuestión permanecerá con esta extensión.

Aunque en principio no parece suponer un riesgo pero imaginémonos que un administrador estaba editando el fichero de configuración de un Wordpress ‘wp-config.php’. Si un atacante intenta determinar si el fichero ‘wp-config.php.save’ existe podrá visualizar su contenido y así extraer las credenciales de la base de datos, si a esto le añadimos que tiene phpMyAdmin instalado y accesible, les estaríamos dando una puerta de acceso a nuestro servidor web.
phpinfo.php En muchas ocasiones al instalar aplicaciones webs estas incluyen en su instalación estos ficheros para verificar la configuración de PHP.
Por tanto si su servidor web tiene instalado PHP sería recomendable denegar este tipo de fichero.
leeme
readme
licencia
license
changelog
.txt
.htm
.html
Estos ficheros están presentes en la mayoría de las aplicaciones web o componentes de CMS que se instalen, suelen contener información acerca de la versión usada, configuraciones por defecto, etc…
Por tanto también es importante denegar estos tipos de ficheros para que la tarea de identificación de servicios no sea tan fácil para cualquier atacante.
log Siempre existe la posibilidad de que cualquier aplicación web genere un fichero de log en directorio web.
.php3
.php5
En numerosas ocasiones atacantes usan estas extensiones que PHP interpreta para evadir filtros donde por ejemplo la extensión .php esta denegada en un directorio de subida.
README Extensión comúnmente usada para ficheros README que puede permitirnos dar información acerca del software instalado en numerosas ocasiones.
filepart Extensión asociada a la aplicación WinSCP, mientras se transfiere un fichero el fragmento mantiene con esta extensión, en ocasiones la transferencia falla dejando expuestos fragmentos del código fuente del archivo.

Mod_Evasive
Este módulo está diseñado para evitar ataques de denegación de servicio contra nuestro servidor Web, a continuación vamos a explicar una serie de directivas aconsejables para intentar mitigar este tipo de ataques.

Hay que añadir a la configuración de Lighttpd los módulos que usaremos, por tanto añadimos la directiva para cargar este módulo.


En primer lugar vamos a denegar el número de conexiones máximas que una IP puede realizar sobre nuestro servidor añadiendo la siguiente directiva, en el siguiente ejemplo se limitó a 10 este valor.


Mod_Expire
Este módulo quizás no este tanto relacionado con el hardening pero si con el rendimiento, proporcionando una caché a tipos de ficheros que se definan en las directivas.

Lo ideal es tener las hojas de estilo, scripts e imágenes en servidores CDN (Content Delivery Network) aunque muchas veces por problemas de recursos esto no es posible, una buena alternativa es usar este módulo para que el navegador tenga en caché estos tipos de ficheros que son los que más tráfico de red generan en nuestro Servidor Web.

El propósito, es que el Servidor Web responda sólo a peticiones que no tiene el navegador del cliente en su caché, reduciendo notablemente la carga y la velocidad del sitio.

En el siguiente ejemplo se definió una caducidad de una semana para tipos de fichero como imágenes, hojas de estilo y scripts.


Mod_AccessLog
Este módulo registra todo tipo de solicitudes realizadas por Lighttpd en archivos, pipes o syslog. El formato de salida de estos registros se puede personalizar usando distintas directivas.


En el formato de salida descrito anteriormente se añade el registro de las peticiones realizadas por el método POST.

HTTP Security Headers 
A continuación definiremos una serie de directivas para añadir cabeceras de seguridad a la respuesta que nuestro Servidor Web le dará al cliente, las cabeceras básicas que la mayoría deberían incluir son las que se definen a continuación, aunque hay muchas más.

Cabecera Descripción
X-Frame-Options Esta cabecera permite evitar ataques de Clickjacking, de manera que el navegador no rechazará cualquier contenido que venga desde un FRAME.
X-XSS-Protection Esta cabecera permite a los dominios y sitios activar o desactivar las protecciones de ataques de XSS
X-Content-Type-Options Esta cabecera permite evitar ataques de MIME Type Confusión. De manera que el servidor sólo cargará hojas de estilo y scripts si su MIME Type es correcto.
Content-Security-Policy Con esta directiva definimos una política de seguridad de contenidos.
Es decir definimos las fuentes desde las que se cargarán las hojas de estilo, scripts, flash,etc...
Strict-Transport-Security La información y el propósito de esta cabecera está descrito más abajo en el apartado de HSTS.

Las directivas para incluir las siguientes Cabeceras de Seguridad en Lighttpd son:


Denegar acceso a IP’s
En ocasiones nos encontramos cualquier IPs que está tratando de acceder a contenidos restringidos, molestos bots, etc…para denegar el acceso a una IP podemos usar esta directiva:


SSL
En las siguientes directivas se desactivó la compresión en TLSv1.0 (CRIME), se deshabilitó los protocolos SSLv2 (FUBAR) y SSLv3 (POODLE), se añadió una curva elíptica, una clave de Diffie Hellman y se desactivaron cifrados débiles como RC4 (BEAST) y DES definiendo así otros protocolos modernos de cifrado como son AES:


Foward Secrecy & Diffie Hellman
Para generar un parámetro DHE fuerte usaremos la herramienta de openssl:


Una vez generado dicho fichero añadimos la siguiente directiva para añadir los parametros de Diffie-Hellman (DH)

 

HTTP Strict Transport Security (HSTS)
El protocolo HTTP Strict Transport Security (HSTS)  estandariza el mecanismo por el cual los servidores web se "declaran" accesibles únicamente a través de protocolo seguro. (HTTPS)
Cuando realizamos una petición a través de HTTP y es redirigida a HTTPS, el cliente realiza la primera conexión sin encriptar antes de ser redirigido.

Esto abre potencialmente ataques tipo MITM (Man In The Middle), ya que la primera petición puede ser interceptada para modificar el sitio seguro original.

Incluso con la lista precargada STS, HSTS no puede evitar ser víctima de ataques avanzados como BEAST o CRIME porque los ataques son contra TLS/SSL en sí.

El estándar propuesto para HSTS está definido en RFC 6797 publicado.

El módulo que usaremos para definir HSTS es mod_setenv el cual es necesario cargar previamente en la directiva server.modules y ser usado solamente cuando se realiza una conexión segura (HTTPS) y nunca cuando se utiliza HTTP.


El valor ‘max-age’ está representado en segundos y define cuanto tiempo el operador del servidor web está dispuesto a comprometerse a utilizar solamente HTTPS, es recomendable establecer un valor grande como 31536000 (12 Meses) o 63072000 (24 Meses).
Por otro lado con ‘includeSubdomains’ indicamos que la política STS aplica a cualquier subdominio.

Aparte en los ficheros del servidor web hay que implementar HSTS, en el ejemplo siguiente se muestra un ejemplo de la implementación en PHP.


Hearthbleed
Es una vulnerabilidad publicada en Abril de 2014 y descubierta por Neel Mehta del equipo de Google Security en la librería criptográfica de OpenSSL, que es muy usada para la implementación del protocolo TLS (Transport Layer Security).

A continuación se describen que versiones de OpenSSL son vulnerables según los investigadores de esta vulnerabilidad:

Versión ¿Vulnerable?
OpenSSL 1.0.1g NO
OpenSSL 1.0.1 hasta 1.0.1f SI
OpenSSL 1.0.0 NO
OpenSSL 0.9.8 NO

Puede consultar referencias de esta vulnerabilidad en los siguientes enlaces:
User Agent Deny
A continuación vamos a definir una serie de políticas que nos ayudarán a prevenir qué herramientas de análisis de vulnerabilidades, scripts automatizados, robots, crawlers, mailers, scriptkiddies pueden navegar por nuestro sitio.

Obviamente este tipo de filtro se puede evitar cambiando el User Agent del navegador pero son muchas las herramientas que incluyen estos valores sin dar opción a cambiarlos.

Por ejemplo Acunetix usa tres cabeceras para realizar sus análisis, que siempre están presentes, como son Acunetix-Product, Acunetix-Scanning-agreement y Acunetix-User-agreement a excepción del editor HTTP que permite deshabilitarlas temporalmente, pero vienen activas por defecto.

Se podrían también añadir unas directivas usando el módulo ModMagnet de Lighttpd para denegar el acceso si se detectan algunas de estas cabeceras.

Pero realmente nos vamos a centrar en denegar acceso mediante los User Agents que suele englobar la mayoría de estas herramientas, a continuación voy a incluir un resumen de la lista de los User Agents que se deberían denegar.

User Agent Descripción
Acunetix Escáner de vulnerabilidades
Arachnini Escáner de vulnerabilidades
Binlar Spider
Blackwidow Escáner de vulnerabilidades
Brutus Herramienta de hacking
Casper Escáner de vulnerabilidades
clsHTTP Bot
DirBuster Herramienta de hacking
EmailCollector Mail spider
EmailSiphon Mail spider
EmailWolf Mail spider
FHscan Escáner de vulnerabilidades
FlashGet Herramienta de descarga
Harvest Herramienta de hacking
Havij Herramienta de hacking
Internet Ninja Herramienta de análisis
JBroFuzz Herramienta de hacking
JOC Web Spider Spider
LWP Perl App (LWP)
Libwww Perl App (libwww)
Nessus Herramienta de hacking
Net Vampire Herramienta de descarga
NetSpider Spider
Nikto Herramienta de hacking
NSAuditor Herramienta de hacking
OpenVAS Herramienta de hacking
PageGrabber Herramienta de descarga
SQLMap Herramienta de hacking
Sucuri Herramienta de hacking
WebBandit Herramienta de hacking

En el siguiente ejemplo sólo se añaden cinco User Agents pero se pueden ir añadiendo más a la lista e ir actualizándola, la directiva a usar para denegar esto es:


Mod_Rewrite
Los módulos se pueden usar para propósitos que no son comunes, por ejemplo ahora vamos a ver de qué modo nos puede proteger mod_rewrite ante accesos no autorizados.

Por lo general la gente suele definir directivas donde si la IP no es válida le lance un forbidden, en principio esto nos sirve para el propósito pero no es la forma más idónea de realizar esto ya que damos información de que dicho directorio estaba presente y le aplicamos dicha directiva.

La idea es usar Mod_Rewrite para montar los directorios dependiendo si la IP proviene de una fuente fiable, montarle los respectivos directorios Web y si no es autorizada montar otros directorios, de manera que sea invisible para un atacante determinar si un fichero o directorio existe.


En el ejemplo descrito anteriormente lo que definimos es que si la IP viene de 222.111.222.111 permita accede a los directorios private/ y phpmyadmin/ y si no montamos un index.html en raíz y el fichero robots.txt lo definimos también accesible.

También podemos usar este módulo para ocultar extensiones de ficheros que permitan a atacantes identificar las distintas tecnologías usadas, o incluso suplantar estas extensiones de tipo de ficheros.

File Hijacking
En numerosas ocasiones sitios de terceros usan recursos de nuestro sitio como por ejemplo imágenes. Cada vez que se realizan este tipo de peticiones desde terceros, se consume ancho de banda, de manera que podemos denegar el acceso a sitios externos al nuestro con la siguiente directiva.



Autor: José Carlos Expósito - CEH
Departamento de Auditoría

Nuevo reglamento de Protección de Datos Europeo

El origen de la protección de datos de carácter personal en España, se remonta al artículo 18 de la constitución española de 1978, sobre el derecho a la intimidad familiar y personal y el secreto de las comunicaciones, desarrollándose en 1992 mediante la ley Orgánica de Regulación del Tratamiento Automatizado de los Datos de Carácter Personal (LORTAD).

Esta legislación fue completada en Junio del año 1999 con el Real Decreto 994/1999 de Medidas de Seguridad (RMS) a implantar sobre los ficheros automatizados que contenían datos de carácter personal. Meses más tarde, en diciembre de 1999, las Cortes españolas aprobaron la Ley Orgánica 15/1999, de 13 diciembre, de Protección de Datos de Carácter Personal (en adelante, LOPD) que derogaba la LORTAD y que continúa aún vigente a fecha actual.

Posteriormente, en 2007, se aprobó el Reglamento de Desarrollo de la LOPD, aprobado por Real Decreto 1720/2007, de 21 de diciembre (en adelante, RLOPD) que desarrollaba la ley LOPD y derogaba el RMS con el objetivo de definir no sólo las medidas de seguridad sobre ficheros automatizados si no, incorporar las medidas de seguridad sobre ficheros no automatizados o en papel.

En la actualidad, la LOPD y RDLOPD están vigentes como normativas a aplicar por las empresas que almacenen y traten datos de carácter personal en territorio español o estén afectados por la legislación española en aplicación de normas de Derecho Internacional Público. Si bien, esta legislación está en proceso de evaluación, ya que el 15 de Diciembre del 2015 la Comisión Europea, el Parlamento Europeo y el Consejo de la Unión Europea alcanzaron un acuerdo sobre un texto de compromiso que se espera que sea aprobado durante el año 2016 y que definirá nuevas obligaciones en materia de protección de datos. Este documento será de aplicación, previsiblemente, en el año 2018.

En su artículo 3, como introducción, define el objetivo de este nuevo reglamento:
El tratamiento de datos personales debe ser diseñado para servir a la humanidad. El derecho a la protección de datos personales no es un derecho absoluto; debe ser considerado en relación con su función en la sociedad y ser equilibrado con otros derechos fundamentales, de conformidad con el principio de proporcionalidad. El presente Reglamento respeta los derechos fundamentales y observa los principios reconocidos en la Carta de los Derechos Fundamentales de la Unión Europea, consagrado en los Tratados, en particular el derecho al respeto de la vida privada y familiar, el hogar y las comunicaciones, el derecho a la protección de datos personales , la libertad de pensamiento, de conciencia y de religión, la libertad de expresión e información, la libertad de llevar a cabo un negocio, el derecho a un recurso efectivo ya un juicio justo, así como la diversidad cultural, religiosa y lingüística.

Las novedades que propone este nuevo reglamento respecto a la actual LOPD son las siguientes:
  • Inclusión de muestras biológicas como dato personal
  • Especial protección a los niños.
  • Incorpora el derecho al olvido (art. 17)
  • Se establece la figura del Data Protection Officer (Sec. 4, art. 35) complementando al responsable del fichero como experto en protección de datos. Cabe destacar que esta figura no tiene porqué ser empleado directo de la compañía, si no que puede ser una figura externa.
  • Desaparece la obligación del registro de ficheros en la agencia de protección de datos (sec 3. Art 33)
    • Para ello, se ha sustituido por el desarrollo de un análisis de impacto en los casos de operaciones y flujos complejos de datos personales.
    • Este análisis de impacto deberá llevar asociado una serie de recomendaciones sobre medidas de seguridad a aplicar en cada una de las soluciones tecnológicas para proteger los datos personales que se traten.
    • Cabe destacar que este análisis de impacto, únicamente deberá desarrollarse en procesos que traten una gran cantidad de datos personales y sobre los que se haya detectado un alto riesgo de fuga o interés externo sobre ellos.
  • Obligatoriedad de comunicar a las autoridades los incidentes de seguridad detectados en menos de 72 horas. En caso de no poder ser notificado en este plazo, se deberá acompañar de la información necesaria que justifique el haber superado dicho plazo.
  • Establecimiento de iconos estandarizados que indiquen, tanto la recolección de datos, como su tratamiento y finalidad (art 12).
  • Aplicación del concepto de ventanilla única, con el fin de agilizar los trámites en los derechos de los ciudadanos (art 54a).
  • Incremento cuantitativo de las sanciones a aplicar. Con el fin de prevenir comportamientos irregulares, se hacen efectivas las nuevas sanciones:
    • Sanciones de hasta 10.000.000€ o el 2% de la facturación bruta anual (la cantidad que sea mayor).
    • Sanciones de hasta 20.000.000€ o el 4% de la facturación bruta anual, en caso de que se puedan aplicar agravantes (datos especialmente protegidos, negligencia, intencionalidad).
Como hemos dicho anteriormente, este nuevo reglamente prevé comenzar a aplicarse a partir de 2018, dando la oportunidad, tanto a proveedores como empresas a familiarizarse con la norma, así como iniciar una transición hacia este nuevo reglamento que implique los menores inconvenientes posibles.

Cabe destacar que este nuevo reglamento intenta aunar los esfuerzos de todos los países europeos en materia de protección de datos, ofreciendo al ciudadano una mayor transparencia por parte de las empresas y un mayor nivel de seguridad en el cuidado de sus datos. Esto se traduce en una colaboración más estrecha entre las autoridades y las empresas, dando lugar a la aparición de nuevos modelos de retención de datos y un acceso más sencillo a su rectificación, cancelación y oposición.

Autor: Juan Miguel López Riesco - CISA, CISM, ISO 27001 Lead Auditor
Departamento Consultoría

¿Por fin un Safe Harbour 2.0?

A raíz de la sentencia de Facebook todos somos conscientes de la complicación surgida  en el  tema de transferencias de datos a EE.UU.

El Tribunal de Justicia de la UE invalidó el  6 de octubre la decisión de la CE que admitía la situación de "puerto seguro", bajo lo cual se permitían transferencias internacionales de datos, considerando que la empresa u organización bajo dicho amparo, tenía un nivel adecuado de protección de los datos de carácter personal, esta situación ha provocado la necesidad de negociar un nuevo marco de actuación con EEUU.
La sentencia abría además la puerta a que  las Agencias de Protección de datos nacionales investigaran si las empresas estadounidenses ofrecen suficientes garantías, que tendrían que ser equivalentes para autorizarlas a los de la UE.

Esta situación ha creado una incertidumbre sobre el modo de actuación que debe llevarse a cabo por parte de las empresas que se ven en dicha situación. El pasado martes, Vera Jourova (Comisaria europea de Justicia), anunció un acuerdo político entre Estados Unidos y la Unión Europea para el nuevo protocolo en materia de Safe Harbour, denominado Privacy Shield.

El marco que reemplazará al actual  Safe Harbour, podría estar aprobado antes de verano.

Jourova indicó que se va  a preparar un proyecto de decisión "en las próximas semanas" y que teniendo en cuenta el procedimiento el nuevo mecanismo podría estar en vigor "en tres meses", recordemos que este plazo  es porque debe contar con la aprobación de los estados miembros de la UE y el Grupo del Artículo 29, que aúna a todas las Agencias de Protección de Datos Europeas.

Los principales cambios que plantea el acuerdo son:
  • Se limita el acceso de las agencias de investigación de EE.UU. a los datos personales de los europeos.
  • Se potencian los sistemas de resolución de conflictos entre ciudadanos y compañías.
  • Se amplía el poder de intervención de las agencias de protección de datos europeas.
  • Se fija que el 'Privacy Shield' será revisado cada año.
  • Aparece una nueva figura, el defensor de los derechos.
Habilitar mejores procedimientos de control a través de este nuevo acuerdo dará a los usuarios mayor seguridad jurídica al facilitar la posibilidad de denunciar las situaciones en que se  vulneren sus derechos.

No obstante y a pesar de esta situación de avance,  las empresas no deberían esperar al texto definitivo del acuerdo  y  deberían seguir notificando su situación a la AEPD.


Autor: Carmen Areces
Departamento Comercial.

Privacy Shield, nuevo marco internacional de transferencia de datos



El pasado 2 de Febrero de 2016, la Comisión Europea anunció la próxima definición de un nuevo marco de privacidad, que regulará las transferencias internacionales de datos personales de ciudadanos Europeos a los Estados Unidos, llamado “Privacy Shield". En dicha entrada, analizaremos el contexto internacional que ha llevado a la creación de dicho marco, así como las características más destacadas del mismo.

La Directiva de Protección de datos de la Unión Europea, en vigor desde el año 1998, prohibía que se transfirieran datos personales de ciudadanos europeos a otros países fuera de la Unión que no cumplieran con unos requisitos mínimos  de seguridad y protección, cosa que dificultaba las relaciones comerciales entre Europa y los Estados Unidos (hay que tener en cuenta que las leyes estadounidenses de protección de datos personales son más laxas que las Europeas). Para facilitar las relaciones comerciales entre los Estados Unidos y Europa, en el año 2000 fue aprobado el acuerdo de Puerto Seguro (Safe Harbor), desarrollado por el Departamento de Comercio de Estados Unidos, en colaboración con la Unión Europea, y que permite a las compañías de Estados Unidos las transferencias internacionales de este tipo de datos. Para que dicho acuerdo fuera válido, las empresas de Estados Unidos debían cumplir con las medidas de seguridad de datos indicadas en la Directiva 95/46/CE, que establecía los siguientes principios clave:
  • Información: Los ciudadanos deben ser informados en todo momento de que sus datos personales están siendo recogidos y que serán tratados únicamente con la finalidad para la que fueron recogidos.
  • Elección: Los ciudadanos tienen el derecho de cancelación y/o oposición a que sus datos sean recogidos una vez hayan sido recabados, y pueden oponerse en cualquier momento a la cesión o transferencia de dichos datos a un tercero.
  • Transferencia progresiva: La cesión de datos a terceros debe llevarse a cabo con organizaciones que también garanticen un adecuado nivel de cumplimiento de protección de datos.
  • Seguridad: Deben establecerse y cumplirse determinadas medidas de seguridad para prevenir pérdidas de información y accesos no autorizados a los datos personales.
  • Integridad: Los datos deben ser relevantes y exactos según el propósito para el que fueron recogidos.
  • Acceso: Los ciudadanos podrán acceder en todo momento a la información que haya sido recabada acerca de ellos, y podrán corregirla o eliminarla si es inexacta o inadecuada.
  • Ejecución: Las compañías deben destinar medios y recursos para garantizar el debido cumplimiento de los principios anteriormente citados.
Las compañías de Estados Unidos que se aprovechaban de dicho marco, debían demostrar el cumplimiento de las anteriores directrices de manera anual, renovando el certificado establecido para tal efecto.

No obstante, durante todos los años de vigencia del Safe Harbor,  dicho marco fue criticado por los países miembros de la Unión Europea, ya que siempre se había considerado que los requisitos de seguridad que establecía eran muy laxos y fáciles de cumplir por las compañías implicadas, y que por lo tanto, se encontraba muy por debajo del nivel de exigencia de la Unión Europea para la protección de datos de sus ciudadanos. Hay que recordar además, que las leyes Europeas en este aspecto son cada vez más estrictas, como lo demuestra la reciente actualización de su reglamento de protección de datos.

Además, el Safe Harbor pasaba por encima de las leyes y regulaciones de protección de datos locales de cada país de la Unión Europea, como por ejemplo la Ley Orgánica de Protección de Datos (LOPD) vigente en España, quitando potestad a dichas regulaciones locales en favor de los requerimientos indicados en Safe Harbor.

En este clima de críticas, y después de las filtraciones de Edward Snowden, indicando el supuesto espionaje y análisis de datos llevado a cabo por parte de la NSA sobre los datos personales de los ciudadanos en Facebook, un ciudadano austríaco decidió llevar a juicio a dicha red social en el Comisionado de Protección de Datos de Irlanda (homólogo de la Agencia Española de Protección de Datos), por el tratamiento inadecuado de sus datos personales. Finalmente, hace poco más de cuatro meses, el 6 de Octubre de 2015, el Tribunal de Justicia de la Unión Europea emitió una sentencia en favor de este ciudadano europeo, anulando el acuerdo Safe Harbor.

Dicho tribunal, indicaba que:

"La existencia de una Decisión de la Comisión que declara que un país tercero garantiza un nivel de protección adecuado de los datos personales transferidos no puede dejar sin efecto ni limitar las facultades de las que disponen las autoridades nacionales de control".
Desde entonces, las transferencias internacionales de datos quedaron en el limbo, y se definió un plazo hasta el 29 de Enero de 2016, para que desde Europa y los Estados Unidos se regularan dicho aspecto.

Así pues, el pasado 2 de Febrero de 2016, la Comisión Europea anunció un acuerdo con el Departamento de Comercio de los Estados Unidos, indicando un nuevo marco de regulación para las transferencias internacionales de datos de ciudadanos Europeos, llamado “Privacy Shield”, o Escudo de Privacidad, que entrará en vigor dentro de tres meses, y que será revisado y actualizado por ambas partes de manera anual, permitiendo su adaptación constante a las nuevas necesidades vigentes.
Aunque por el momento se conocen pocos detalles sobre dicho nuevo marco, la Comisión Europea ha avanzado que cumplirá con las siguientes premisas:
  • Fuertes obligaciones para las compañías que traten datos personales de ciudadanos de la Unión Europea, garantizando los derechos de los mismos. El Departamento de Comercio de los Estados Unidos monitorizará además que las entidades afectadas cumplan con sus obligaciones al respeto.
  • Se establecerán de manera clara y transparente los derechos de acceso del gobierno de los Estados Unidos a los datos personales. Dichos accesos serán limitados, se realizarán con todas las garantías necesarias y no serán generalizados, llevándose a cabo solamente cuando esto sea estrictamente necesario y de forma proporcionada.
  • Se protegerán de manera efectiva los derechos de los ciudadanos, creando la figura de un “Defensor del Usuario”, que vele por las reclamaciones o quejas de los mismos. En caso de que se detecte que se han vulnerado los derechos de los usuarios en relación a sus datos personales, éstos deberán ser compensados por la compañía responsable del tratamiento de dichos datos, con sanciones o multas que serán definidas en cada caso.

Desde Internet Security Auditors, seguiremos atentamente la evolución y definición de dicho marco de privacidad, y en cuando se hagan públicos más detalles y características del mismo, los analizaremos en profundidad en este blog.

Referencias:
http://europa.eu/rapid/press-release_IP-16-216_en.htm
http://www.nytimes.com/2016/02/03/technology/us-europe-safe-harbor-data-deal.html?_r=1
http://blog.isecauditors.com/2016/01/europa-actualiza-el-reglamento-de-proteccion-datos.html
https://es.wikipedia.org/wiki/Principios_internacionales_safe_harbor
https://www.agpd.es
http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:es:HTML
http://curia.europa.eu/jcms/upload/docs/application/pdf/2015-10/cp150117es.pdf
http://tecnologia.elpais.com/tecnologia/2015/10/05/actualidad/1444071970_946053.html

Autor: Guillem Fàbregas - PCI QSA, PCIP, CISSP, CISA, CISM, CRISC, ISO 27001 L.A.
Departamento de Consultoría.
 

Crónica del CIBERSEG'16

La semana pasada, del 25 al 27 de Enero, tuvo lugar la tercera edición de las Jornadas de Seguridad y Ciberdefensa (CIBERSEG'16) en la Escuela Politécnica de la Universidad de Alcalá de Henares. Estas jornadas están organizadas por el grupo de Ingeniería de Servicios Telemáticos, la Cátedra DARS y la Delegación de estudiantes.


Cabe destacar el notable crecimiento y aceptación de estas jornadas. En sólo tres ediciones, ya han conseguido superar los 600 inscritos al evento y, además de las conferencias y talleres (actividades que ya se llevaron a cabo en la anterior edición), este año han incorporado, como novedad, la realización de un CTF (capture-the-flag) de tipo jeopardy, donde los participantes debían resolver determinadas pruebas de distinta tipología para obtener puntos, sin necesidad de defender su propio sistema.

En esta ocasión, las jornadas fueron inauguradas por parte de D. Félix Sanz Roldán, secretario de Estado director del Centro Nacional de Inteligencia, y el Excmo. Sr. D. Fernando Galván Reula, Rector Magnífico de la Universidad de Alcalá.

Además de numerosos estudiantes, al evento acudieron profesionales de la seguridad y tecnologías de la información en general, así como numerosos miembros de distintos cuerpos y fuerzas de seguridad del estado, entre otros asistentes.

Tras una breve bienvenida e introducción a cargo del Rector de la UAH, el secretario de Estado director del CNI nos ofreció una interesante reflexión sobre el estado de la ciberseguridad en España y, entre otros aspectos, nos reveló que dispone de una máquina Enigma en su despacho, momento que aprovechó para comentar su punto de vista sobre la conocida película The Imitation Game.

Como primer ponente de las jornadas, hablé sobre técnicas OSINT. En primer lugar, comentando aspectos relacionados sobre la necesidad de tomar decisiones en nuestro día a día. En ocasiones, determinadas decisiones tienen un gran impacto en la sociedad y quienes han de tomarlas se encuentran bajo una fuerte responsabilidad y presión. A continuación, describiendo el problema del exceso de información que disponemos actualmente así como el de la fiabilidad de las fuentes y, por último, comentando el proceso y las bondades del uso de técnicas OSINT en la ayuda para la toma de decisiones como objetivo final. A modo de ejemplo, y tras ver una clasificación de las herramientas OSINT disponibles, mostré un análisis sobre los atentados de París utilizando la última versión de mi herramienta Tinfoleak.


La segunda ponencia ("Hacking Web: Attacks and Tips") a cargo de Iván Sanz de Castro, tuvo un enfoque práctico sobre un problema ya conocido pero no por ello menos relevante: el de las deficiencias en el código de las aplicaciones, su detección y posterior explotación. Con este enfoque, presentó riesgos recogidos en el Top 10 de OWASP, con un carácter divulgativo y con una gran exposición.

Tras el descanso, llegó el turno de Lorenzo Martínez y su presentación "Memorias de un Perito Informático Forense". Esta presentación, considerada el volumen III de lo que parece ser una larga serie de memorias, nos revela las experiencias de Lorenzo en el mundo del análisis forense. Sobra decir, para quienes conocemos a Lorenzo, que sus exposiciones son muy ilustrativas a la par que divertidas. En esta ocasión, nos expuso otro de los casos con los que ha tenido que lidiar últimamente, siguiendo con detalle los pasos realizados en su investigación que, naturalmente, finalizó con éxito.

El siguiente ponente, al que también tengo el placer de conocer, fue Deepak Daswani y llevó a cabo la presentación "Hack your life for fun and profit". Por desgracia, tuve que ausentarme en esta presentación, por lo que no puedo aportar mi visión sobre la misma, aunque intuyo que debió ser realmente interesante.

Ya en la tarde, tras la comida, Óscar Pastor nos presentó "Los ciberejercicios como herramienta de protección y sensibilización ante las ciberamenazas". Expuso diversos escenarios en los que ISDEFE ha venido trabajando en los últimos años, simulando ataques contra infraestructuras críticas. Estos ciberejercicios, ejecutados por un grupo heterogéno de profesionales, pretenden simular la capacidad de respuesta frente a un ataque real, así como conocer el nivel de protección de las infraestructuras críticas en España. Destacó la ciberamenaza creciente a los sistemas de control industrial, y comentó alguno de los ciberjercicios que se han llevado a cabo desde 2012, incluyendo el último relacionado con un escenario de control ferroviario.

A continuación, tuvo lugar la miniferia de empleo en ciberseguridad. Esta miniferia estaba formada por stands de empleo de algunas de las principales empresas del sector de nuestro país donde, como no podía ser de otra forma, se encontraba Internet Security Auditors. Este espacio, de gran aceptación por los asistentes a juzgar por el número de visitas e interés mostrado, sirvió para poner en contacto a estudiantes y profesionales del sector, con destacadas empresas del sector de la ciberseguridad.

La dos siguientes sesiones, corrían a cargo de antiguos estudiantes de la UAH con dos interesantes presentaciones. En la primera de ellas ("OWADE Reborn"), Carlos Cilleruelo presentaba un proyecto que ya conocía por ser uno de los proyectos que se desarrollaron en el Hackathon de Cybercamp en el que tuve el honor de participar como jurado. Se trata de un fork de OWADE y es una herramienta de código abierto que permite obtener contraseñas de Chrome y Firefox, historial y descargas, Outlook así como contraseñas de sistema operativo, SSIDs y contraseñas de redes WiFi de sistemas Windows 7 y Windows 8. En la segunda sesión, Luís Linazasoro nos presentó "Whatsapp Privacy?", exponiendo sus experiencias en la investigación de las comunicaciones de la archiconocida herramienta de mensajería. Presentó algunos problemas de privacidad que había identificado en el pasado, así como los sistemas de cifrado que ha implementado Whatsapp, pero que aún sufren deficiencias que permiten identificar, entre otros, datos privados como el número de móvil simplemente analizando las comunicaciones. Esta información podría  servir, como indicaba el propio Luís, para ser utilizada por otras herramientas (como las desarrolladas por Deepak Daswani en esta línea).

La última ponencia de las jornadas ("Scanning and Port-Knocking: 1F authentication + 1F authorization") fue impartida por Pablo González. A pesar de su juventud, se ha convertido en un clásico de los eventos de ciberseguridad y al que muchos conocemos. Su presentación versaba sobre cómo facilitar la labor de los administradores de sistemas, protegiendo los servicios expuestos a Internet. En concreto, como revela el título de la presentación, presentaba la técnica port-knocking para llevar a cabo procesos de autenticación (basado en el puerto y la IP origen) combinado con la herramienta Latch para verificar el nivel de autorización. Su presentación culminó con una prueba de concepto que, a pesar de no resultar exitosa, permetía conocer las posibilidades comentadas durante su presentación.

Sin lugar a dudas, unas jornadas muy interesantes cuya evolución habrá que seguir muy de cerca. Mi enhorabuena a la organización de CIBERSEG16 por el éxito conseguido.

Autor: Vicente Aguilera - CISA, CISSP, CSSLP, ITILF, PCI ASV, CEH, ECSP, OPST/A OWASP Spain Chapter Leader.
Director Departamento de Auditoría.