Y es que si algo tiene que fallar algún día, está claro que fallará durante una presentación en directo, durante una importante migración o, como no, durante una contingencia.

Empecemos por la parte organizativa:

Uno de los grandes errores de los planes de continuidad es tener únicamente una serie de documentos técnicos para restaurar HW/SW. Evidentemente esto no podemos considerarlo como un plan de continuidad TIC (véase este post sobre los tipos de los proyectos: http://www.securityartwork.es/2013/04/04/continuidad-de-negocio-tipos-de-proyectos/) ya que se habrá quedado fuera toda la parte organizativa, pero es una situación que encontramos bastante frecuentemente. Esto suele ocurrir cuando no se aborda la tarea como un proyecto en condiciones, sino que se le encarga al departamento de TI “Hacer un plan de esos por si esto explota. Y rapidito que tenéis más cosas que hacer”.

Pues bien, dependiendo de la naturaleza del negocio, la parte organizativa seguramente será mucho más importante que la parte técnica, ya que de nada sirve documentar como restaurar equipos si no hay un local donde hacerlo, si no hay personal de respaldo, o nadie que pueda tomar decisiones relevantes. Por culpa de este tipo de documentos puede pasar que ante una contingencia se dediquen recursos a recuperar antes la aplicación de gestionar las vacaciones del personal que la centralita de atención al usuario u otras situaciones similares.

Al respecto, además de crear la política y establecer prioridades, se tienen que crear los planes clásicos de continuidad organizativa como pueden ser reubicación de personal, sustitución de personal, contacto con proveedores y clientes, etc., los cuales deben ir acompañados de un Plan de Pruebas. Puede parecer que estos planes al no tener componente tecnológica no pueden fallar, pero fallan, y lo peor, hacen que otros planes no puedan ejecutarse. Puede parecer que un plan de reubicación de personal no puede fallar ya que solo hace falta tener, por ejemplo, comunicación con el CPD de respaldo, pero en el momento de la contingencia podemos darnos cuenta de que necesitábamos una impresora con la que no habíamos contado, que las comunicaciones no son suficientes, que el local no tiene mesas, que sin la libreta del 2º cajón del administrador de sistemas no se puede acceder a X servidor, o que nadie recuerda la IP a la que conectar para hacer una tarea ya que todo el mundo la tenía en favoritos y sus equipos están en la ubicación a la que no se puede acceder.

Por otro lado, además de probar los planes con el fin de buscar errores o detalles que hayamos dejado fuera, las pruebas de la parte organizativa sirven como entrenamiento por si llega el día en que hay que utilizarlos. Para un técnico restaurar un sistema puede ser algo relativamente rutinario, pero seguramente la responsabilidad de activar la contingencia y de empezar a lanzar planes recaerá en alguien que no se dedica a hacer esto frecuentemente. El cómo se actúe durante la primera hora será decisivo para el buen funcionamiento del plan ya que una mala decisión puede retrasar todo el restaurado, por lo que es imprescindible que quien tenga que tomar las decisiones tenga cierta soltura y que conozca perfectamente el plan, y esto solo se consigue practicándolo.

¿Y qué ocurre con la parte técnica?

Si en la parte organizativa lo más importante es probarlo todo para familiarizarse con el entorno y ver que no se han dejado cabos sueltos, en la parte técnica nuestro peor enemigo es el “pues esto tendría que funcionar, peeeero…. Por desgracia hoy en día tenemos un montón de tecnologías que nos deberían facilitar la vida ante una contingencia como pueden ser SAIs monstruosos, cabinas de discos inmensas, virtualización por todas partes, sistemas de alta disponibilidad, grupos electrógenos, etc. los cuales nos dan una (falsa) sensación de tranquilidad que puede hacer cundir el pánico si no todo es tan maravilloso como nos han prometido.

Todo es superseguro pero, ¿cuántos se atreven a cortar la luz del CPD sin avisar a nadie confiando en que los SAIs harán su trabajo y que los aires aguantarán? ¿Tirarías del cable de red del cortafuegos principal confiando en que el secundario balanceará perfecto? ¿Borrarías un servidor crítico tranquilamente sabiendo que según el fabricante del robot de copias en 20 minutos lo tienes restaurado? Si alguien contesta a todo que sí o es un valiente o lo tiene todo muy atado (lo cual efectivamente puede suceder).

En la práctica es relativamente frecuente encontrar copias de seguridad corruptas, lentitud en los restaurados o comunicaciones, backups de configuraciones de electrónica de red desactualizados o scripts de restaurado que ya no funcionan con el último cambio que se hizo, y la única forma de detectar estas situaciones es, una vez más, probar que todo funciona.

Resulta además muy recomendable (por no decir necesario) hacer las pruebas técnicas junto con la parte organizativa ya que, por ejemplo, ni se trabaja igual ni se dispone de los mismos recursos en la oficina y en la ubicación alternativa. Detalles como no tener una copia de los certificados de la VPN o del fichero de contraseñas disponible desde una ubicación alternativa, haber olvidado abrir algún puerto en el cortafuegos, o tener las instrucciones técnicas de cómo restaurar una copia dentro de la propia copia, son situaciones que se pueden solventar muy fácilmente, pero que se tienen que detectar antes… ¡PROBÁNDOLO!

¿Y si montamos un teatrillo?

A alguno le parecerá que esto es cosa de modernos, pero una buena forma de hacer las pruebas de la forma más realista posible es hacerlas sin avisar a nadie y añadir dramatismo teatrero como si algo realmente hubiese pasado (aunque todos sepan que no es así): en lugar de convocar una reunión para ver cómo se planifica la puesta en marcha de los planes, se puede montar un pequeño circo en la oficina un día que nadie lo espere y llegar a escenificar que ha sucedido alguna catástrofe y que el negocio no puede operar normalmente. También se puede activar el plan antes de la hora de entrar a la oficina llamando por teléfono a los implicados en las pruebas para que acudan directamente al centro de respaldo, de modo que a nadie le dará tiempo de “hacer trampas” y llevarse la documentación que necesita en un USB, o enviarse al correo la última versión del fichero de claves que ha olvidado actualizar en el repositorio de backup.

Para los más imaginativos se puede incluso montar un pequeño juego de rol, donde un “master” va lanzando cataclismos naturales sobre el CPD, o hace que los técnicos enfermen misteriosamente a medida que los pobres contingente recuperan servicios, pero eso lo contaremos en otra ocasión.

Esperamos que haya quedado claro que si realmente queremos que un plan de pruebas tenga sentido y queremos ver como funcionaríamos ante una contingencia real, no nos vale con restaurar un servidor de forma muestral, o firmar un contrato con un proveedor que nos garantiza el suministro: hay simular que el negocio no puede operar y no quedarse en pruebas de concepto o soluciones a medias.

• Seguridad de las tecnologías de la información y la comunicación (MISTIC). Máster oficial no-presencial impartido por la UOC junto a profesores de la UAB y la URV. La duración estimada es de 1 año (60 créditos), y aunque los idiomas oficiales son el castellano y el catalán, los estudiantes no-parlantes de este último idioma no tendrán ningún tipo de problema. El precio se sitúa sobre los 4100 €.
• Máster universitario en seguridad de tecnologías de la información y comunicaciones. Máster oficial presencial (viernes tarde y sábados) impartido por la UEM. Al igual que el anterior, son 60 créditos. Para más información, consultar su página web.
• Máster en Seguridad Informática. Máster oficial no-presencial impartido por la UNIR. Cómo todos los anteriores, son 60 créditos. Para más información, consultar su página web.

Por otra parte, existen otras certificaciones no-universitarias que son más que interesantes:

• Offensive Security Certified Professional. Consta del curso “Penetration Testing with Backtrack”, cuya duración y precio es variable. Durante el curso, el alumno tendrá acceso a una red de ordenadores (averiguar cuántos es parte del curso), dónde se practicarán todas las fases de un pentest, atacando sin distinguir entre servidores, máquinas de cliente, y distintos sistemas operativos. Desde la experiencia, es posible sacárselo en 2 meses, aunque depende de lo agobiado que quiera y pueda ir cada uno. Los precios oscilan entre los 750 $ (1 mes) y 1100 $ (3 meses). Una vez finalizado el curso, el alumno tiene un periodo de 3 meses para realizar el examen de certificación, que dura 24 horas y en el que debe hacerse con el control de varias máquinas. Finalizadas las 24 horas, tiene otras 24 horas para realizar y entregar el informe. Un curso extremadamente divertido, dónde dormir no es una opción.
• Cracking the perimeter. Es la versión avanzada del curso anterior. Para acceder es necesario superar unas pruebas de admisión, y desembolsar entre 1200 y 1500 $, dependiendo de si se opta por realizarlo en uno o dos meses. En este caso, la duración del examen es de 48 horas.
• Cursos prácticos también son los ofrecidos por www.securitytube.net. Son cursos prácticos bastante asequibles económicamente. Personalmente, me gustan los de desarrollo en Python y ensamblador. También ofrecen de manera gratuita un curso (sin certificación) de Metasploit.

Y cómo siempre está la opción de la autoformación, de la que se ha hablado largo y tendido. Por suerte hoy día existen multitud de sites que ofrecen CTF (Capture The Flags), máquinas virtuales y multitud de documentación de forma totalmente gratuita y desinteresada.

Entiendo que nos dejamos muchas certificaciones (y muy buenas) en el tintero, pero con esta entrada sólo pretendíamos acercar a la gente al mundillo de la seguridad. Por este motivo, no hemos indicado ninguna certificación que requiera su renovación, como pueden ser SANS, CEH, CISSP, y un largo etc.

El principal problema de las nuevas tecnologías es que, aún teniendo la posibilidad de evitar problemas de seguridad conocidos, desafortunadamente, la mayoría de las veces esta no es el objetivo principal, por lo que estos errores se vuelven a repetir una y otra vez. Además de esto, las nuevas tecnologías también tienden a inventar nuevas clases de vulnerabilidad, o nuevas formas para explotar problemas de seguridad conocidos.

Un ejemplo práctico de que lo estoy diciendo es Node.js

¿Qué es Node.js?

El 8 de noviembre de 2009, Ryan Dahl presentó Node.js como un entorno de desarrollo en JavaScript de lado de servidor, totalmente asíncrono y orientado a eventos. Usa el motor de JavaScript V8 de Google, dotando a este entorno de una gran velocidad y agilidad, y sumando además una capacidad de Entrada/Salida realmente ligera y potente. Esto permite construir aplicaciones altamente escalables y escribir código que maneje miles de conexiones simultáneas en un solo equipo. Entre las compañías que usan esta tecnología destacamos LinkedIn, eBay, Yahoo!, Microsoft y nosotros mismos (S2 Grupo).

¿Qué es el V8?

V8 es el motor de JavaScript que Google usa en su navegador Chrome. Un motor normal de JavaScript, interpreta el código y lo ejecuta. El V8 es ultra-rápido, está escrito en C++ y se puede descargar por separado e incorporarlo a cualquier aplicación. Así nace Node.js, cambiando el propósito por el que se creó V8 y usándolo en el lado del servidor.

¿Para qué JavaScript en el lado del servidor?

La meta principal de Node.js es la de proporcionar una manera fácil de construir programas de red escalables. En lenguajes como Java™ y PHP, cada conexión genera un nuevo hilo con su respectiva reserva de memoria. Esto limita la cantidad de peticiones concurrentes que puede tener un sistema. Por ejemplo, un servidor muy común es Apache, el cual crea un nuevo hilo por cada conexión cliente-servidor. Esto funciona bien con pocas conexiones, pero a partir de 400 conexiones simultáneas, el número de segundos para atender las peticiones crece considerablemente. Así pues, Apache funciona bien en entornos clásicos, pero no es el mejor servidor para lograr máxima concurrencia.

Node.js resuelve este problema cambiando la forma en que se realiza una conexión con el servidor. En lugar de generar un nuevo hilo de SO para cada conexión, cada conexión entra en el bucle de ejecución y dispara el evento dentro del “pool” de trabajadores. De esta forma, nunca se quedará en punto muerto, dado que no se permiten bloqueos y no se bloquea directamente las llamadas de E/S, permitiendo así miles de sesiones concurrentes (en un sistema UNIX este límite puede rondar por las 65.000 conexiones).

¿Cuándo usar Node.js?

Node.js está extremadamente bien diseñado para situaciones en la que se espere una gran cantidad de tráfico y donde la lógica del servidor y el procesamiento requeridos sean sencillas para dar una respuesta lo antes posible. Node.js es especialmente bueno en aplicaciones web que necesiten conexiones persistentes con el navegador del cliente. Usando ciertas librerías, en concreto socket.io, puedes hacer que una aplicación envíe datos al usuario en tiempo real; es decir, que el navegador mantenga la conexión siempre abierta y reciba continuamente nuevos datos cuando se requiera. Hay que entender que, aunque se puede usar como servidor de páginas web “clásicas”, no se diseñó para ese fin. Algunos ejemplos de uso:

• Servicios Web que proporcionen APIs RESTful.
• “Timelines” de Twitter.
• Aplicaciones de única página.
• Videojuegos de varios jugadores.
• Aplicaciones tiempo real (Chats, cuadros de mando).

Node.js dispone de un gestor de módulos (librerías, plugins, frameworks) npm (Node Package Manager), que amplían la funcionalidad de este y facilitan tareas. En otro futuro post trataremos de hablar de varios frameworks típicos de Node.js, en concreto de Fusker, que es un firewall de aplicación que previene y maneja una gran cantidad de ataques en Node.js.

Entre estas librerías, destacaremos la ya nombrada Socket.io, que es una librería que nos permite manejar eventos en tiempo real mediante una conexión TCP. Socket.io la cual tiene como objetivo hacer que las aplicaciones en tiempo real sean posibles en todos los navegadores y dispositivos móviles, borrando las diferencias entre los mecanismos de transporte (WebSocket, Adobe® Flash® Socket, AJAX long polling, AJAX multipart streaming, Forever Iframe, JSONP Polling).

Estas comunicaciones se pueden poner detrás de un servidor clásico como podría ser Apache o Nginx tal y como explica Vicente Domínguez en su post.

Un poco de código

Para comenzar, podemos descargar Node.js de la página de la aplicación http://nodejs.org/, para varios sistemas. En mi caso he realizado las pruebas con la última versión (tar.gz) para Linux.

Una vez descargado y funcionando vamos a comenzar escribiendo la aplicación en un fichero js. Editamos un archivo “ejemplo-1.js” y escribimos el siguiente código:

var http = require('http');
http.createServer(function (req, res) {
     res.writeHead(200, {'Content-Type': 'text/plain'});
     res.end('Hello World\n');
}).listen(1337, '127.0.0.1');
console.log('Server running at http://127.0.0.1:1337/');

Ahora desde la consola lanzamos la aplicación:

$ node ejemplo-1.js

Para los que no estéis familiarizados con JavaScript, existen multitud de tutoriales en internet, no es el propósito de este post explicar línea por línea que hacen los programas. En resumen, vemos que “ejemplo-1.js” crea un servidor que escucha en el puerto 1337 y, ante cualquier petición a http://127.0.0.1 devuelve un texto plano “Hello World”.

En el siguiente post, apoyándome en la presentación que hizo Sven Vetsch (Redguard AG – www.redguard.ch) para el Application Security Forum de 2012, trataré de mostrar cómo pueden afectar las clásicas vulnerabilidades (XSS reflejado, inyección de JS en el servidor, ejecución de código remoto).

Una de las cosas que más le llamó la atención a mi compañero de mesa en la oficina (quién venía de trabajar en el ámbito de la ingeniería industrial), fue la increíble capacidad que tenemos los profesionales del sector de las Nuevas Tecnologías para encadenar siglas en una misma frase, como en la siguiente frase: Las copias de respaldo se hacen en un dispositivo NAS que implementa RAID 5 configurado con cifrado AES de 256 bits, con mantenimiento NBD.

El objetivo de este post es tratar de hacer un pequeño repaso de algunos términos que habitualmente se escuchan en el mundillo de las TIC, los cuales se refieren a aspectos como control de acceso, redes, cifrado, cumplimiento legal, cumplimiento de la normativa, entre otros. Les pido a nuestros estimados lectores que me concedan la licencia de resumirles de un modo breve y sencillo cada uno de estos conceptos:

AD/DA (Active Directory / Directorio Activo): Sistema proporcionado por Microsoft para la gestión centralizada de recursos de red, incluyendo la gestión de políticas aplicables, gestión de usuarios y equipos, sistema de autenticación, etc.

AES (Advanced Encryption Standard): Algoritmo de cifrado simétrico con tamaño de llave de 128 a 256 bits.

ARCO (Acceso, Rectificación, Cancelación y Oposición): Derechos que los usuarios pueden ejercer sobre la gestión de sus datos personales por parte de una entidad (Responsable de Fichero). Estos derechos comprenden el acceso, la rectificación, cancelación y la oposición de los datos.

BCP/PCN (Business Continuity Plan / Plan de Continuidad de Negocio): Procedimientos documentados que especifican el proceso que debe seguir una organización para recuperar y restaurar sus funciones críticas o niveles de servicio tras un evento disruptivo.

DBMS/SGBD: (Data Base Management System / Sistema de Gestión de Base de Datos): Software que permite la gestión tanto de acceso, almacenamiento, escritura y lectura de la información dispuesta en una base de datos. Ejemplos de estos sistemas son Oracle e Informix.

CERT (Computer Emergency Response Team): Equipo de personas dedicado a la gestión de la seguridad de la información y a la repuesta ante incidentes y ataques. También conocido como CSIRT (Computer Security and Incident Response Team).

CMDB (Configuration Management Data Base): Concepto del marco ITIL, que hace referencia a una base de datos que recoge los distintos activos dentro de los sistemas de información y la relación existente entre ellos.

CPD (Centro de Proceso de Datos): Emplazamiento, sala o estancia donde se albergan los servidores de una organización.

DLP (Data Loss Prevention): Solución diseñada para detectar potenciales fugas o filtración de información y prevenirlas mediante monitorización, detección y bloqueo de información sensible mientras está en uso (acciones del usuario), en transmisión (tráfico de red) y en almacenamiento. Incluyendo el uso de entornos email, web, equipos de usuario, smartphones, etc. Existen soluciones de diversas marcas como Symantec, McAfee o Cisco.

DoS (Denial of Service): Ataque que pretende impedir a los usuarios hacer uso de determinados servicios de red, ya sea por consumo de recursos, alteración de información de configuración o de estado, etc. Los ataques emplean los protocolos TCP/IP y generalmente son ataques de inundación.

DMZ (Demilitarized Zone): Segmento de red ubicado entre la red interna de una entidad y el acceso a internet. El acceso desde esta red a la red interna está bloqueado. En esta red se ubican servidores que gestionan servicios accesibles externamente como FTP, Email, etc.

DRP (Disaster Recovery Plan): Estrategia que define una organización para restaurar los servicios TI.

HA (High Availability): Término que hace referencia al diseño de sistemas (generalmente mediante la redundancia de componentes), garantizando la disponibilidad de los servicios que soportan estos sistemas a pesar de haber potenciales fallos o averías de los componentes de dicho sistema.

HVAC (Heating, Ventilation and Air Conditioning): Hace referencia a sistemas de climatización.

IDS (Intrusion Detection System): Sistema software o hardware que mediante la monitorización del tráfico de una red permite la detección de ataques conocidos, así como de comportamientos o patrones sospechosos (escaneos de puertos, ataques de denegación de servicio, etc).

IPS (Intrusion Prevention System): Sistema software o hardware que además de la funciones que proporciona un IDS, incluye el bloqueo o detención de ataques conocidos, así como comportamientos o patrones sospechosos.

IPSEC (Internet Protocol Security): Extensiones del protocolo IP empleado para comunicaciones, proporciona autenticación y cifrado. Se implementa a nivel de capa 3 (OSI) y generalmente se emplea para la creación de túneles cifrados (VPN).

LDAP (Lightweight Directory Access Protocol): Protocolo de acceso unificado que permite el acceso a un servicio de directorio ordenado y distribuido en un entorno de red.

NAC (Network Access Control): Solución que emplea un conjunto de protocolos para permitir acceso únicamente a nodos de una red (equipos de usuarios) que cumplan determinadas políticas de seguridad, como puede ser: existencia de antivirus, actualizaciones o configuraciones del sistema operativo.

NAP (Network Access Protection): Adaptación de la solución NAC propuesta por Microsoft.

NAS (Network Attached Storage): Hace referencia a soluciones de almacenamiento compartido a través de red (normalmente TCP/IP), haciendo uso de un Sistema Operativo optimizado para dar acceso a protocolos como CIFS, NFS o FTP. Por norma general son dispositivos de almacenamiento específicos, no obstante un servidor configurado para compartir archivos por red podría ser considerado un NAS.

NBD (Next Bussines Day): Generalmente se utilizan para indicar que el tiempo de atención para el soporte, mantenimiento o cualquier otra garantía será atendida o resuelta en el siguiente día laborable.

NOC (Network Operation Center): Instalaciones desde las que se controlan y monitorizan redes de comunicaciones.

NTP (Network Time Protocol): Protocolo de sincronización de relojes para sistemas. Se suele referenciar al control 10.10.6 Sincronización de relojes de la ISO 27002.

OLA (Operation Level Agreement): Acuerdo interno de una organización donde se establecen los niveles de servicio entre distintos departamentos de la misma organización.

PCI-DSS (Payment Card Industry Data Security Standard): Normativa de seguridad de la información definida por el PCI Security Standards Council, aplicable a todas las entidades que participan en procesos de pago con tarjeta y el cual recoge los requerimientos técnicos y operativos desarrollados para proteger los datos de los usuarios. Su adopción es obligatoria desde junio de 2007 y las marcas pueden imponer sanciones a las entidades que no realicen las auditorías prescritas.

RF (Resistente al Fuego): Criterio que evalúa la capacidad de un cerramiento de contener un incendio, se mide en minutos, por ejemplo RF90. Este criterio ha sido sustituido por tres criterios: R (Resistencia), E (Integridad) e I (Aislamiento).

RPO (Recovery Point Objective): En continuidad de negocio, hace referencia al periodo de tiempo máximo de pérdida de datos tras un incidente. Este valor viene marcado por la política de copias de respaldo o sincronización de sistemas.

RSA (Iniciales de Rives, Shamir y Adleman): Algoritmo de cifrado basado en clave pública. El tamaño mínimo de clave se considera 1024 bits lo cual equivale a 80 bits en cifrado simétrico. No obstante se aconseja emplear claves de 2048 bits como mínimo.

RTO (Recovery Time Objective): En continuidad de negocio, hace referencia al periodo de tiempo requerido para restaurar servicios o actividades tras un evento disruptivo.

SAN (Storage Area Network): Es una red dedicada al almacenamiento que proporciona acceso a nivel de bloque. La principal diferencia con la NAS es que por norma general se emplea fibra para conectar los servidores a la SAN y los NAS van por red local, por otra parte para hacer uso de la SAN los equipos con acceso deben disponer de un interfaz de red específica para la SAN. Generalmente la SAN es empleada cuando se requieren un alto nivel de rendimiento y el coste de la infraestructura es mucho mayor que la de un NAS.

SLA/ANS (Service Level Agreement/Acuerdo de Nivel de Servicio): Contrato escrito entre un proveedor de servicio y su cliente con objeto de fijar el nivel acordado para garantizar la calidad de dicho servicio.

SFTP (Secure File Transfer Protocol): Protocolo del nivel de aplicación que proporciona la funcionalidad necesaria para la transferencia y manipulación de archivos sobre un flujo fiable de datos. Utiliza por norma general SSH para proporcionar la capa de seguridad.

SNMP (Simple Network Management Protocol): Protocolo de nivel de aplicación para el intercambio de información de administración entre dispositivos de red. Permite a administradores la supervisión del funcionamiento de la red. Cuenta con tres componentes claves: dispositivo administrado, agentes y sistemas administradores de red.

SSL (Secure Socket Layer): Protocolo de seguridad en las comunicaciones mediante el uso de cifrado. Este proporciona autenticación y confidencialidad de la información. Generalmente el servidor es el que se autentica. Implica el uso de cifrado de clave pública y posteriormente cifrado del tráfico mediante protocolos de cifrado simétrico.

SSO (Single Sign On): Procedimiento de autenticación que habilita al usuario para acceder a varios sistemas con una sola instancia de identificación.

TLS (Transport Layer Security): Protocolo que supone la evolución de SSL.

UPS/SAI (Uninterruptable Power Supply/Sistema de Alimentación Ininterrumpido): Dispositivo que proporciona energía eléctrica por un tiempo limitado ante fallos en el suministro eléctrico. Se emplea para limitar los riesgos asociados a caídas repentinas de suministro que puedan afectar a los sistemas de información críticos.

WSUS (Windows Server Update Server): Servicio para proporcionar las actualizaciones de seguridad para los sistemas operativos de Microsoft, permitiendo que las actualizaciones de los distintos equipos se descarguen de modo centralizado.

XSS (Cross Site Scripting): Ataque asociado a aplicaciones web, que consiste en inyectar en páginas web vistas por el usuario código en lenguaje script, evitando medidas de control. Este tipo de ataque permite secuestrar sesiones de usuarios, entre otros.

Estoy seguro de que la mayoría de nuestros lectores conocían el significado de estos acrónimos. No obstante, nunca viene mal recordar… A veces la memoria nos juega malas pasadas. Es probable que me haya dejado algún término, pero creo que esto será suficiente para defenderse de los envites de los auditores a los que se enfrenten ;)

*Para la definición de algunos de los términos anteriormente descrito se ha empleado como principal fuente wikipedia.org

El protocolo implementado ya en todos los navegadores permite unas nuevas líneas de comunicación cliente-servidor bidireccionales que desde el punto de vista de la seguridad se deben tener en cuenta. Además, desde la administración de sistemas (que es lo que toco), sí existe la responsabilidad de diseñar una buena arquitectura que ayude a la seguridad de todo el conjunto aunque al final uno queda a merced del buen código del propio desarrollo.

Mirando desde el lado del cliente ya existen en la red ciertos documentos (véase Shekyan Toukharian – Hacking Websocket Slides) de cómo cualquier ejecución no autorizada sobre protocolos embebidos en el navegador, como puede ser javascript, pueden lanzar comunicaciones que vayan por estos canales bidireccionales que proporciona los websockets en background. Todo ello sin el conocimiento del usuario.

Por otro lado, desde el punto de vista del servidor, la perspectiva puede ser otra.

Como la comunicación entre el cliente (navegador) y el servidor es necesariamente directa para mantener esos canales, ciertas instalaciones acaban exponiendo sus servidores sobre los que se soportan los websockets. Realmente esto no sería mayor problema si se realizase correctamente pero sí que lo puede ser cuando dicha exposición, para permitir la comunicación, conlleva que el backend quede alcanzado desde fuera para que los navegadores, y desde ese momento todo Internet, puedan acceder a él.

Los inconvenientes son dos muy claros:

• No es posible la aplicación eficiente de reglas cuando son los navegadores de móviles, navegadores de portátiles y n-mil dispositivos de internet los que tienen que acceder al server vía websockets.
• Multitud de servidores necesitan de extensiones no instaladas en los ISPs para su uso.

La conclusión de estos inconvenientes es que en ocasiones se opta por la exposición directa del backend como ya comentábamos (o la no implementación de websockets, con la renuncia evidente a sus características). Sin embargo, hay multitud de LB (loadbalancers) que SÍ soportan websockets: haproxy, nginx desde hace poquillo, varnish…. y también los hay que hasta la fecha usaban implementaciones más controvertidas: apache con mod_pywebsocket, que no obstante, no es de todos los gustos.

Realmente hay cientos de arquitecturas pero para hoy vamos a elegir como ejemplo Nginx con Node.js y Sockect.io.

Las implementaciones de Socket.io son sencillas. Es autocontenido y el trabajo con sockets del propio Socket.io permite que se pueda optar por un acceso directo contra el puerto del Node.js. No obstante, si el despliegue de Node.js lo hacemos desde el backend (por un tema de intercomunicación y escalabilidad) exponemos un servicio que tal vez no era necesario. La alternativa tal vez podría ser optar por “encapsular”, y por tanto abstraer el acceso al Node.js a través de un segundo dominio y gracias a un nginx por ejemplo.

Nginx nos permite también una exquisita creación de hilos en caso de picos y nos proporciona un buen nivel de abstracción para websockets desde su versión 1.3.x (que no recomiendo porque anda con algún importante bug de seguridad). Así que nos metemos en la 1.4.1 ya que las versiones anteriores no soportan estas comunicaciones.

El proceso es sencillo. Únicamente vamos a necesitar un nombre de dominio adicional a nuestra config (si ya hubiera una). Esto nos permite de forma muy sencilla desmarcarnos del resto de funciones que esté realizando nginx (web, vídeo, etc etc) y usar la funcionalidad de websockets únicamente para ese nombre de dominio (servers en nginx).

Tenemos que crear un upstream para el control de los backends y creamos sock.midominio.es

Al final la implementación sería algo como:

upstream websockets_nodejs {
        server backend:9090;
}

server {
        listen       80;
        server_name  sock.midominio.es;
        root   /usr/local/app/sock/app/webroot;
        keepalive_timeout  512;

        location / {
                proxy_pass  http://websockets_nodejs;
                proxy_redirect off;
                proxy_http_version 1.1;
                proxy_set_header        Host            $http_host;
                proxy_set_header        X-Real-IP       $remote_addr;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header        Upgrade $http_upgrade;
                proxy_set_header        Connection "upgrade";
        }
}

Varias anotaciones:

• server backend:9090: backend es un nombre de /etc/hosts y 9090 es el puerto por defecto donde se levanta nodejs.
• keepalive_timeout: mejor corto que largo por tema de recursos pero si el código no es capaz de controlar la conexión es posible indicar un número superior para evitar algunos comportamientos anómalos.
• El resto de líneas son de manual. Únicamente faltaría indicar en nuestro desarrollo como acceder al server que gestiona los websockets indicando nuestro nuevo dominio y si, todo por el puerto 80.

Con esto acabamos de incorporar un nivel de abstracción más sobre nuestra arquitectura delegando al buen hacer de nginx el control y gestión de las conexiones contra el backend Node.js+Socket.io.

Evidentemente es posible configurarlo sobre SSL sin problemas:

upstream websockets_nodejs {
        server backend:9090;
}

server {
        listen       443;
        server_name  sckts.midominio.es;
        root   /usr/local/app/sock/app/webroot;
        index index.php;
        keepalive_timeout  512;

        ssl                  on;
        ssl_certificate      /etc/nginx/server.crt;
        ssl_certificate_key  /etc/nginx/server.key;

        ssl_session_timeout  5m;

        ssl_protocols  SSLv2 SSLv3 TLSv1;
        ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
        ssl_prefer_server_ciphers   on;

        location / {
                proxy_pass  http://websockets_nodejs;
                proxy_redirect off;
                proxy_http_version 1.1;
                proxy_set_header        Host            $http_host;
                proxy_set_header        X-Real-IP       $remote_addr;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header        Upgrade $http_upgrade;
                proxy_set_header        Connection "upgrade";
        }
}

Ahora en la configuración de vuestro desarrollo deberéis conectar sobre https.
En nuestro entorno de pruebas ha ido de maravilla aunque siempre habrá alguien que podrá apuntar más datos interesantes sobre estas arquitecturas. En ese caso, bienvenido sea.

Como ya se comentó en entradas anteriores de este hilo, de cara a emplear o validar un certificado o firma digital, uno de los puntos más importantes es la confiabilidad del mismo, ya que, como se comentó, cualquiera puede generar una clave asimétrica e incluir los campos que desee en el certificado. De nuevo en base a este hecho surge la necesidad de la existencia de Autoridades de Certificación (CA), quienes se encargan de emitir certificados confiables y reconocidos. Pero, ¿como sabemos que el certificado que tenemos entre las manos ha sido emitido por una de estas entidades?

Aunque se comentará en próximas entradas el formato X.509 como estándar de generación de certificados digitales, es importante destacar que, como es natural, dicho formato contiene campos para introducir los datos del emisor (issuer). Es obvio que estos campos nos pueden parecer útiles para este fin; pero del mismo modo que el resto de campos del certificado pueden ser fijados al gusto de quien lo genere, por lo que en absoluto suponen una garantía de procedencia y autenticidad del certificado digital.

Para cubrir estas necesidades surge el modelo de cadena de confianza. Este modelo establece una relación entre certificados que permite asegurar, sin duda alguna, que dicho certificado ha sido emitido por una Autoridad de Certificación. Veamos en primer lugar como se implementa este modelo.

Como algunos habrán adelantado, la solución más obvia será firmar el certificado emitido con un certificado que “represente” a la CA. De este modo, si el certificado que firma es confiable, tenemos total certeza de que el certificado ha sido emitido por una CA, y por tanto quien lo emplea debería ser quien dice ser (siempre y cuando no se vulnere su clave privada, en la próxima entrada veremos de qué mecanismos se vale la CA para revocar y validar certificados, así como cómo dispone esta información al alcance de los usuarios finales de los mismos). Todo esto parece que suena bien, sin embargo, nos sigue dejando en el mismo punto del que partimos, ¿cómo sé que el certificado que firma el anterior es válido?

En el modelo de cadena de confianza jerárquico, las Autoridades de Certificación disponen de un certificado conocido como Certificado Raíz (Root CA), y como su nombre indica es el certificado que validará todos y cada uno de los certificados emitidos por la CA; sin embargo, este certificado no es el que firmará los certificados de suscriptor (o certificados finales), sino se empleará únicamente para firmar los denominados Certificados Subordinados (Sub-CA), y estos últimos firmarán los certificados de suscriptor (o finales). Se muestra un diagrama ejemplo del modelo jerárquico para ilustrar el funcionamiento de la cadena de confianza de certificados:

Es importante destacar que, en general, las Autoridades de Certificación emiten los certificados intermedios orientados a generar certificados de suscriptor en base a distintas tipologías, usos o unidades de negocio (por ejemplo certificados de persona física, persona jurídica, SSL, firma de código, etc.).

Sin embargo, el principal motivo de tomar esta decisión es proteger al máximo Certificado Raíz de la jerarquía. En base a los conceptos explicados en entradas anteriores, si un tercero consiguiera la clave privada de un Certificado Raíz, se comprometerían todos y cada uno de los certificados emitidos con la misma (es más sería capaz de emitir certificados en nombre de la CA). Visto de este modo, cobra sentido que los certificados finales no estén firmados con esta clave; además que en base a éste modelo jerárquico, un certificado de suscriptor firmado por el raíz no sería de suscriptor sino subordinado, con todo lo que conllevaría dar esa clave a un usuario. Este hecho propicia que se considere normalmente la clave privada del certificado raíz como la información de mayor valor y más crítica de la CA. Debido a ello, es habitual que la clave privada del certificado raíz se encuentre offline, en un dispositivo de seguridad cifrado y con medidas de alta seguridad (que también se comentarán en próximas entradas).

De cara a la validación del certificado firmado tanto por el certificado raíz como su subordinado, la CA mantiene online todas las claves públicas de su jerarquía; aunque habitualmente se suelen adjuntar al certificado de suscriptor (como se muestra en el ejemplo posterior). De modo que para validar un certificado de un suscriptor, se deberá comprobar la firma para toda la cadena de confianza de la CA emisora, quedando así clara la procedencia del mismo.

Por último, y siguiendo con la línea de ejemplos planteada en entradas anteriores, se muestra la información de la cadena de confianza del certificado SSL de www.bankia.es, que en este caso ha sido generado por VeriSign, Inc. (autoridad de certificación propiedad de Symantec).

Como se puede observar en la imagen, se describe la jerarquía de certificados de VeriSign que ha generado este certificado se suscriptor. Lo detallamos a continuación:

• Certificado Raíz: VeriSign Class 3 Public Primary Certification Authority
• Certificado Subordinado: VeriSign Class 3 Extended Validation SSL SGC CA
• Certificado de Suscriptor: www.bankia.es

El proceso de validación lo suelen realizar de forma automática los navegadores web, de modo que aunque el certificado no estuviera auto firmado (self signed), si detectara una incoherencia en la cadena de certificación consideraría el certificado no confiable y avisaría al usuario como se detalló en la entrada Fundamentos sobre Certificados Digitales (II).

A modo de curiosidad, dejo unos cuantos enlaces que os ayudarán a ver un ejemplo práctico de jerarquía de certificados, concretamente la de Verisign (Symantec):

• Listado de Certificados Raíz de Verisign: http://www.verisign.com/repository/root.html
• Descarga de certificados Raíz de Verisign: https://www.symantec.com/page.jsp?id=roots
• Listado de Certificados Subordinados de Verisign: http://www.verisign.com/support/verisign-intermediate-ca/index.html
• Jerarquía de Certificados de Verisign: http://www.verisign.com/repository/hierarchy/hierarchy.pdf

Dejo también una entrada referente al escándalo de TURKTRUST, en el que por error se firmaron dos certificados de suscriptor directamente con el certificado raíz, lo que tuvo consecuencias desastrosas: http://www.securitybydefault.com/2013/01/algunas-reflexiones-sobre-el-ultimo-ca.html

Gracias de nuevo por leernos y como siempre quedo a la espera de vuestros comentarios.

Prácticamente a diario, instalamos aplicaciones en nuestros PCs y smartphones, nos registramos en redes sociales o servicios diversos. Todos estos proveedores de aplicaciones y servicios se cuidan mucho sus espaldas, y no se arriesgan a dejar resquicios legales.

Y nosotros, como usuarios, aceptamos sin saber lo que estamos aceptando. Principalmente, yo diría que por dos razones:

Como todos, soy de esas personas que al llegar al paso de aceptar los términos y condiciones y ver ese scroll que parece ser infinito voy directamente a la famosa casilla y afirmo estar de acuerdo con algo que no he leído.

Pero ahora que estoy rodeada de gente que sabe de seguridad y se preocupa por la privacidad, estoy empezando a plantearme cosas a las que antes no les daba tanta importancia.

Así que como usuaria asidua de Google y sus servicios, me he propuesto leer y analizar las condiciones que acepté en su día y que se aplican en unos servicios que utilizo a diario.

Lo primero que me ha llamado la atención es que el lenguaje utilizado no es tan incomprensible y rebuscado como me esperaba. En la mayoría de los puntos, queda bastante claro a qué hacen referencia y qué cabe esperar al respecto. De otros servicios no puedo hablar, pero al menos en este caso, descubrir que se pueden leer y entender sin ser licenciado en Derecho invalida el punto 2 que he mencionado antes.

Algunos puntos que considero merece la pena remarcar:

El principio suena muy bien, dejan muy claro que lo tuyo es tuyo. Pero luego resulta que estás autorizando a Google (y sus colaboradores, que no he conseguido determinar quiénes son) a usar, reproducir, crear obras derivadas etc. Y seguirán teniendo derecho a hacerlo incluso si tú dejas de usar sus servicios.

No deja de ser curioso que, en cualquier momento y sin justificación previa puedan modificar o cancelar los servicios que ofrecen. Hay quien dice que, siendo gratis no te puedes quejar ante posibles cambios o cierres de servicios (claro que no es gratis, ya que pagas con tus datos). Pero eso no ha evitado por ejemplo el revuelo provocado por el cierre de Google Reader. Al menos parece que han cumplido la parte de avisar con antelación y permitirte extraer la información.

Para acabar, el salvavidas definitivo: todos los usuarios hemos aceptado que los términos aceptados pueden ser modificados unilateralmente (muy importante el “por ejemplo” de la segunda línea: se mencionan dos posibles motivos de cambio, pero no todas las razones que pueden alegar para modificar las condiciones). Y aceptamos que debemos ser nosotros quienes revisemos cada cierto tiempo las condiciones para detectar posibles cambios. Me gustaría conocer una estadística del número de usuarios que sigue esta recomendación… Pero lo hagamos o no, hemos aceptado estas condiciones y ellos tienen la sartén por el mango.

He de reconocer que la lectura no ha sido tan terrible como esperaba, y que no me quedo con la sensación de haber vendido mi alma a Google a cambio del uso de sus servicios. Pero varios de los puntos de las condiciones de servicio de Google remiten a la política de privacidad, a la que también he echado un vistazo y he encontrado bastantes cosas reseñables, pero ese análisis lo dejaremos para otra ocasión, por no extendernos demasiado.

Casualmente, mientras estaba terminando de redactar esta entrada, muy satisfecha por haberme leído los términos y la política de privacidad, me encuentro con esta noticia sobre “algo” llamado PRISM que me genera nuevas inquietudes. ¿Son conscientes o no las empresas del acceso que los gobiernos tienen a la información que manejan? Si los gobiernos pueden acceder a ella sin consentimiento de las empresas ¿para qué sirve tanta política de privacidad, tantos términos de uso y tantas condiciones a aceptar?

Y lo más importante: ¿qué podemos hacer nosotros, como usuarios de a pie, para proteger nuestra información y nuestros datos?

Cada día se almacenan enormes cantidades de información, por lo que sistemas gestores de bases de datos relacionales están dando paso al fenómeno big data, que cada vez despierta más interés y expectativas en las organizaciones. De hecho, muchas empresas están abriendo nuevas líneas de negocio, creando plataformas SaaS que se dedican exclusivamente a analizar cantidades titánicas de información e identificar aquella que podría tener un valor importante para las decisiones estratégicas de muchas corporaciones.

Para aquellos que todavía no están familiarizados con el término, se trata de la nueva generación de tecnologías para el acceso, procesamiento, análisis y visualización de enormes volúmenes de datos. Entre estas surge toda una tipología de bases de datos NoSQL y plataformas de procesamiento big data, sistemas robustos que ofrecen elevadas capacidades de escalabilidad, baja latencia, y un esquema libre de modelo para el almacenamiento flexible de datos. Así, tenemos familias para el almacenamiento de datos en forma de clave-valor (key-value), orientados a colecciones, columnas, persistencia de estructuras de datos en forma de grafos, etc. Uno de ellos es Storm (el lector precavido ya puede estar intuyendo de donde proviene la inspiración para el título de esta entrada).

Storm es el sistema distribuido para el procesamiento de flujo de datos, actualmente propiedad de Twitter, aunque originalmente fue desarrollado por la compañía Blacktype. Fiable y tolerante a fallos, garantiza que cada mensaje inyectado en el flujo se procesará de forma completa. A diferencia de otras plataformas de procesamiento de datos como Hadoop o Cascading, Storm realiza el procesamiento del flujo de datos en tiempo real. El componente encargado de llevar a cabo ese procesamiento se llama topología. A su vez, ésta está formada por varias abstracciones que explicaremos más adelante. Cuando la carga computacional se incrementa de forma considerable se hace trivial aumentar el paralelismo de la topología para que se ejecute en varios procesos distribuidos en multitud de máquinas físicas. Si se produce un fallo durante el procesamiento, Storm se encargará de reasignar el trabajo a las tareas, además de garantizar que no habrá pérdida de ningún mensaje gracias a la naturaleza transaccional de las topologías. Otra de las ventajas de Storm, es que permite la ejecución de consultas distribuidas (DRPC) paralelizables al vuelo, ideal para los escenarios donde es necesario lanzar queries intensas u otras operaciones exigentes.

Es usado por multitud de organizaciones tales como Groupon, Alibaba, The Weather Channel, y como no, Twitter. Podemos ver la lista completa de empresas y proyectos que usan Storm. No tenemos que olvidarnos de mencionar que se trata de una plataforma open source, y aunque está desarrollada en una combinación de Clojure y Java, Storm es completamente agnóstico de lenguaje, por lo que nada nos limita a crear las topologías en otros lenguajes de programación.

El cluster de Storm está compuesto por dos tipos de nodos:

• Nodo maestro, es el nodo principal donde se ejecuta el demonio llamado Nimbus, encargado de asignar tareas a los nodos worker, monitorizar posibles fallos, distribuir el código a lo largo del cluster, etc.

• Nodos worker alojan el demonio llamado Supervisor que ejecuta la porción de la topología entre varios procesos que incluso puedan estar ejecutándose en múltiples máquinas.

La coordinación y el estado de ejecución entre los nodos se mantiene en ZooKeeper, o bien se persiste en disco duro cuando se ejecuta en modo local, y es precisamente esto lo que hace que Storm sea tan robusto y estable.

Las topologías se ejecutan continuamente hasta que se solicite explícitamente su terminación. Éstas están formadas por dos tipos de componentes que se agrupan en un grafo. Unos llamados spouts representan la fuente de entrada de flujo de datos en el sistema y generan listas de tuplas. Los spouts pueden inyectar datos en la topología bien consumiendo mensajes de las colas de los sistemas de mensajería, consultando la API de terceros vía REST, leyendo registros desde la base de datos, o cualquier otra fuente que se nos ocurra. Los bolts consumen las tuplas emitidas por spouts u otros bolts, para aplicar cualquier tipo de transformación o lógica específica al flujo de datos, ya sea filtrado, agrupaciones, funciones, agregaciones, etc. En el siguiente diagrama podemos ver la estructura simplificada del cluster de Storm.

Para dar un enfoque pragmático e ilustrar las capacidades de Storm, vamos a desarrollar una sencilla aplicación para procesar datos obtenidos desde las redes sociales. Usaremos el API de Facebook, para recuperar los estados que han ido publicando nuestros amigos y los mandaremos a una cola RabbitMQ. A continuación desarrollaremos los componentes de la topología – uno se encargará de consumir los mensajes de la cola y generar tuplas con el estado y el publicador (spout), y el resto aplicarán las transformaciones correspondientes para separar cada estado en palabras, contar las ocurrencias de las mismas y mostrar el top 20 de palabras más utilizadas en los estados de nuestros amigos en tiempo real. En la imagen podemos ver el grafo de spouts y bolts que forman nuestra topología.

El código completo de la aplicación se encuentra en el repositorio github, por lo que no vamos a entrar en detalles de implementación. Tan solo mencionaremos que los spouts deben implementar la interfaz IRichSpout y los bolts la interfaz IRichBolt. Los métodos importantes de los spouts, son nextTuple donde se obtiene el flujo de datos y se generan las tuplas, y el par ack / fail para confirmar o bien señalizar el fallo en el procesamiento de la tupla. Esto es importante, ya que la emisión de una tupla por un spout puede desencadenar la generación de muchas tuplas en otros componentes, por lo tanto se considera que un mensaje se ha completado satisfactoriamente cuando se procesa correctamente el árbol de tuplas generadas.

A la hora de ensamblar la topología podemos especificar las preferencias de paralelismo, tanto el número de tareas como el número de procesos workers. El último argumento del constructor de los componentes especifica el paralelismo. TopologyBuilder nos permite construir la topología que más tarde se desplegará en el cluster:

TopologyBuilder topologyBuilder = new TopologyBuilder();
topologyBuilder.setSpout("status-emitter", new AmqpStatusEmitterSpout() );
topologyBuilder.setBolt("status-splitter", new StatusSplittingBolt())
        .shuffleGrouping("status-emitter");
topologyBuilder.setBolt("status-segmentator", new StatusSegmentatorBolt(),
        5).fieldsGrouping("status-splitter", new Fields("word"));

StatusSegmentatorBolt se ejecutará de forma paralela entre 5 hilos de ejecución.

A raíz de todo lo que hemos dicho, podemos concluir que Storm es una plataforma prometedora y gracias a su modelo de programación sencillo, la curva de aprendizaje del mismo es corta y no tendremos que preocuparnos por detalles de sincronización, paralelismo o mantenimiento del estado y coherencia en el procesamiento de los mensajes.

Si ya en la versión del 2011 el ciberespacio cobraba importancia como un nuevo ámbito en el que nuestro país se enfrenta ante amenazas y riesgos:

En la nueva versión se plantea la ciberseguridad como uno de los principales ámbitos de actuación de dicha Estrategia.

En el tercer capítulo de la Estrategia, “Los riesgos y amenazas para la Seguridad Nacional”, se describen los riesgos y amenazas que afectan a la Seguridad Nacional, y entre otros aparecen las ciberamenazas, el espionaje (este riesgo no era considerado como tal en la versión de 2011), la proliferación de armas de destrucción masiva, o la vulnerabilidad de las infraestructuras críticas y los servicios esenciales. También se contemplan otros factores potenciadores como la generalización del uso nocivo de las nuevas tecnologías que, sin ser en sí mismos un riesgo o una amenaza pueden desencadenarlos.

En el cuarto capítulo se definen unas “Líneas de acción estratégicas” -dentro de doce ámbitos de actuación- que enmarcan las actuaciones concretas necesarias para la preservación de la Seguridad Nacional. Para el sector de la Seguridad de la Información podrían ser destacables los siguientes ámbitos y sus líneas de acción:

Ciberseguridad

Dentro de las líneas de acción se destaca lo siguiente:

• Incremento de la capacidad de prevención, detección, investigación y respuesta ante las ciberamenazas con apoyo en un marco jurídico. Impulso de los recursos necesarios.
• Fortalecimiento de la seguridad de los sistemas de la información y las redes de comunicaciones que soportan las infraestructuras críticas. Se impulsará la normativa sobre protección de infraestructuras críticas con el desarrollo de las capacidades necesarias para la protección de los servicios esenciales.
• Se impulsarán y liderarán actuaciones destinadas a reforzar la colaboración público-privada.
• Promoción de la capacitación de profesionales en ciberseguridad e impulso a la industria española a través de un Plan de I+D+i.

No proliferación de armas de destrucción masiva

Me llama la atención una de sus líneas de acción “Se adoptarán medidas preventivas de vigilancia en relación con el uso de la red”.

Contrainteligencia

Se pretende, entre otros, garantizar la disposición de los medios técnicos necesarios para contrarrestar esta amenaza.

Protección de Infraestructuras Críticas

Comentar que, en cuanto a líneas de acción llamativas, el que se dotará a estas instalaciones de sistemas redundantes e independientes de otras tecnologías y operadores.

CIBERATAQUES. CONTEXTUALIZACIÓN

Quizá se pueda entender un poco más esta Estrategia en el ámbito de la ciberespacio contextualizando un poco de manera histórica la implicación que tienen los ciberataques en la Seguridad Nacional. Recordemos que existen precedentes de cómo un país puede sufrir serios daños ante un ciberataque o cómo puede utilizarse en un acto de terrorismo. En el año 1985, un grupo terrorista denominado Middle Core Faction atacó el sistema que controlaba los ferrocarriles de alta velocidad en Japón, cortando primero el suministro eléctrico y los cables de control informatizados del ferrocarril y luego interceptando e interfiriendo las radiocomunicaciones de la policía para ralentizar su capacidad de respuesta. Nadie resultó herido pero este ataque afectó a 6,5 millones de usuarios y tuvo un coste económico de unos seis millones de dólares.

En la década de los 90, los ciberataques cobran mayor importancia y comienzan a usarse como una fuente más de ataque en diversos conflictos bélicos como la Guerra del Golfo, la Guerra entre Serbia y Croacia o la Guerra de Kosovo con diversos objetivos: robo de información estratégica, protesta o manipulación de la información. A partir del año 2000 y en especial en la segunda mitad de la década, este tipo de ataques se incrementan marcando importantes hitos. En 2008, Georgia sufre diversos ataques de DDoS contra sitios gubernamentales e Irán en 2010 recibe varios ciberataques que afectan a muchas de sus centrales nucleares.

Posteriormente, Canadá en 2011 detectó que se habían producido intrusiones en bases de información del Gobierno que contenían datos altamente confidenciales y durante 2012 países como Irán, Israel, Palestina, Siria o Sudán han visto como eran objetivo de un ataque dirigido diseñado para la recopilación y robo de información estratégica, y que hacía uso de una de las herramientas de ciberataque más sofisticadas descubiertas hasta la fecha: Flame. Durante este 2013, se descubre la operación “Red October”, diseñada para robar información de las instituciones gubernamentales de distintos países (entre ellos España), “APT1”, grupo militar del ejército chino encargada de ciberinteligencia a nivel mundial y la reciente operación de ciberespionaje que ha saltado a la palestra “NetTraveler” en la que España se encuentra entre los 10 países más afectados.

Es evidente que con el descubrimiento de malware avanzado capaz de manipular maquinaria industrial y la existencia de los ataques dirigidos (campañas de APT) contra objetivos críticos para la seguridad nacional, ha quedado demostrado que la posibilidad de que un ataque cibernético cause catástrofes o altere el funcionamiento normal de un país, es un riesgo presente. Un análisis interesante sobre las implicaciones en la seguridad nacional por parte de los ataques dirigidos, los orígenes,objetivos y las consecuencias de los mismos puede encontrarse en el estudio que recientemente publicó CSIRT-cv junto con INTECO-CERT y en el que participó el equipo de S2 Grupo que trabaja en CSIRT-cv, “Detección de APTs” y del que ya hablamos en este post.

Pero no solo la manipulación directa a infraestructuras críticas por parte de atacantes puede poner en jaque la seguridad de un país; el robo de determinada información sensible (sobre material armamentístico, patentes o tecnologías críticas, plantas nucleares, relativo a comunicaciones, estrategias gubernamentales, etc.) también puede poner en entredicho asuntos concernientes a la seguridad nacional. A día de hoy el ciberespionaje es un arma muy poderosa para desestabilizar la defensa de un Estado.

En el ámbito empresarial, hace unos años que el espionaje industrial a través de Internet está en auge y se ha consolidado como una práctica común; el robo de información valiosa para las empresas supone no sólo una pérdida económica importante causada por el robo de la propiedad intelectual y por el desembolso de dinero realizado para la remediación, sino porque también puede proporcionar ventajas a la competencia o provocar un daño reputacional, en algunos casos irreparable.

La manipulación del sistema financiero de un país también puede afectar de manera muy crítica a la estabilidad de un Estado. En la actualidad, no es descabellado pensar que a través de ataques cibernéticos, un grupo terrorista o país enemigo, sea capaz de detener, alterar o manipular el sistema financiero de un país. Es un hecho constatado que la economía tiene una gran dependencia de los sistemas informáticos y la infraestructura tecnológica de un país, por lo que la solidez y el progreso económico del país dependerá en parte de la seguridad de nuestro ciberespacio.

Fuentes:

• Estrategia de Seguridad Nacional 2013: http://www.lamoncloa.gob.es/NR/rdonlyres/5A600DAD-CFEF-45C1-84F0-DF5B06684E26/0/EstrategiaSeguridad_3105.pdf
• Detección de APTs: http://www.csirtcv.gva.es/sites/all/files/downloads/Detecci%C3%B3n_APT.pdf

Lecturas interesantes:

• El Gobierno aprueba controles preventivos ante la ciberguerra: http://politica.elpais.com/politica/2013/05/31/actualidad/1370027040_282333.html
• Cinco escenarios de ciberguerra en el nuevo orden mundial:
  http://www.eldiario.es/turing/escenarios-ciberguerra-nuevo-orden-mundial_0_129837338.html

La investigación, realizada por Jérôme François, Shaonan Wang, Radu State, y Thomas Engel, en su documento intenta mostrarnos cómo detectar botnets P2P utilizando NetFlow y una extensión del algoritmo PageRank utilizado por Google.

El documento nos cuenta las arquitecturas habituales de botnets y la evolución que están sufriendo hacia arquitecturas distribuidas, para aumentar la escalabilidad principalmente. Para detectar estas nuevas arquitecturas, proponen lo siguiente:

Tal y como explican, en primer lugar se dispone de un colector netflow (por ejemplo la herramienta ntop con el plugin de netflow) que recoge los flujos de routers, honeypots, etc. Con estos flujos se hace un grafo de relación entre hosts. Este grafo es analizado por un módulo que implementa una versión del algoritmo PageRank de Google que según el autor es un algoritmo apropiado para analizar los enlaces de comunicación entre los hosts en redes grandes. Como resultado de procesar el grafo con estos algoritmos se obtienen dos valores, el hub rank (Partiendo de los nodos origen tráfico hacia los nodos destino) y el authority rank (Partiendo de los nodos destino tráfico hacia los orígenes), que tienen en cuenta la dirección del tráfico para calcularlos. La puntuación de cada nodo será mayor dependiendo de la cantidad de conexiones que tenga con otros nodos y de la calidad de esas conexiones. Por ejemplo, el nodo que es un honeypot distribuirá mayor peso a los nodos con los que está relacionado, y se considerará por tanto una conexión importante (mayor peso), ya que la probabilidad de que un nodo relacionado con él forme parte de una botnet es muy alta.

Partiendo del hub rank y authority rank de cada nodo el módulo de cluster agrupará con el objetivo de identificar nodos con un rol similar dentro de la red. El ejemplo que ponen en el documento es el cálculo de hub rank y authority rank para el protocolo kademlia, para hosts normales y para bots, de manera que se vea la distribución de los valores y sea posible comparar. En este caso se ve cómo ha identificado dos clusters de bots principales:

Es posible por tanto obtener unos rangos de valores que permitan identificar una botnet utilizando un protocolo p2p según lo que nos cuentan en este estudio. Os recomiendo su lectura dado que puede aportaros ideas para la explotación del tráfico NetFlow para la detección de botnets p2p.