Recientemente he tenido la oportunidad de leer un artículo sobre privacidad en las comunicaciones móviles titulado Cellular Telephony and the Question of Privacy ($) donde entre otras cosas se plantea un sistema que garantice la privacidad del acceso a las redes móviles, separando la identidad del terminal de la identidad del usuario mediante un sistema PKI.

En el sistema propuesto, el terminal dispone de un modo de funcionamiento privado donde este envía una petición PER (Privacy Enabling Registration) a la red del operador; dicha petición consiste en un mensaje de certificación que valida al usuario y un valor aleatorio denominado RET (Random Equipment Tag), que se incluirá en los registros VLR (Visitor Location Register) y HLR (Home Location Register) del operador, los cuales permiten enrutar y mantener las llamadas, pero sin asociarlos a un usuario determinado (los siguientes mensajes de registro incluyen peticiones PET en lugar del número de télefono).

En España, la Ley de conservación de datos relativos a las comunicaciones electrónicas y a las redes públicas de comunicaciones (Ley 25/2007 de 18 de octubre) indica que los operadores de telefonía móvil con servicios prepago deberán registrar la identidad de los clientes que acceden a la red. Aparte de esta ley, cada vez es más habitual que la privacidad y el anonimato en la red se muestren como una problemática real, y ya comienzan a aparecer servicios de Internet integrados con sistemas de identificación como el DNI electrónico, como por ejemplo ha hecho Tuenti recientemente.

Sin entrar en detalles técnicos que seguro que hay muchos que se me escapan y a la vista de un entorno legislativo y político cada vez más preocupado por trazar y registrar todo tipo de comunicaciones, ¿piensan que un sistema así podría ser factible? Y desde otro punto de vista, ¿es necesario o deseable?

Hace un par de semanas se realizó en Valencia una jornada de seguridad organizada por ISMS Forum donde pude asistir, entre otras, a una charla de Jelle Niemantsverdriet (el principal consultor forensics de Verizon), quien, aparte de remarcar la importancia de los logs para llevar a cabo sus análisis —importancia que también se ha remarcado en distintas entradas en este blog—, presento brevemente el framework VERIS desarrollado por Verizon.

El framework VERIS (Verizon Enterprise Risk and Incident Sharing) proporciona un lenguaje común para describir incidentes de seguridad de forma estructurada y repetitiva, basado en lo que denominan las cuatro ‘A’:

Recientemente he tenido que volver a repasar parte del funcionamiento del Adaptive Security Algorithm de Cisco. De manera breve, este algoritmo es el encargado de inspeccionar el tráfico y permitir o denegarlo basándose en las políticas existentes.

A grandes rasgos, cuando una conexión llega al sistema, es procesada mediante el Session Management Path, quien se encarga de comprobar la tabla de rutas y NAT y las listas de control de acceso, de forma que si la política definida permite el tráfico, se crea una nueva entrada en la tabla de estados mediante el Fast Path, que es el encargado de revisar las cabeceras 3 y 4, comprobar el checksum IP, números de secuencia TCP, etc. El resto de paquetes de la conexión ya establecida son enviados directamente al Fast Path. La conjunción del Session Management Path y del Fast Path es lo que se conoce como Accelerated Security Path (ASP).

Habitualmente, cuando hablamos de enrutamiento ya sea en un router, un firewall o un servidor conectado a varias redes, siempre se hace referencia a enrutamiento por destino, es decir, si quiero llegar desde el nodo A hasta el nodo B, miro en mi tabla de rutas la forma más rapida (mejor métrica) de alcanzar el nodo B y envío el tráfico por la ruta especificada. Si no tengo ninguna ruta especifica al destino, usaré la ruta por defecto, no obstante, hay ocasiones en que esto no es suficiente.

Cuando hablamos de continuidad de negocio y planes de recuperación ante desastres, siempre nos vienen a la mente alternativas de recuperación del tipo Cold, Warm y Hot Sites dependiendo del RTO requerido por nuestra organización. No obstante, existen otras alternativas de recuperación menos conocidas (o al menos, menos aplicadas), por ejemplo los conocidos como Mobile Sites.

A grandes rasgos, un Mobile site no es más que un trailer que contiene toda la tecnología necesaria para dar soporte a una organización que se ha visto afectada por un desastre (generalmente con un RTO de entre 3 y 5 días), el cual puede ser ubicado de forma fácil en una zona considerada segura. Un ejemplo de este tipo de alternativa de recuperación ante grandes desastres (por ejemplo en el reciente terremoto de Japón) es el conocido como Cisco NERV (Network Emergency Response Vehicle). Este vehículo es capaz de conectarse vía satelite y proporcionar a la organización servicios de voz, vídeo y datos allí donde se requiere su presencia, tanto acceso a Internet como a redes remotas.

El sistema consiste en una serie de equipos capaces de proporcionar servicios de Routing, Firewalls, VPN, sistemas de vigilancia CCTV, equipos de conferencias de voz y datos, sistemas de telepresencia, telefonía IP (mediante CUCME), conectividad Wireless o integración con sistemas de radio mediante la funcionalidad LMR (land mobile radio) proporcionada por los routers y el sistema IPICS (Cisco IP Interoperbility and Collaboration System).

El vehículo también dispone de una serie de baterías, SAIs y su propio generador por si el suministro eléctrico se ha visto afectado por el desastre. Podemos encontrar información mas detallada sobre el vehículo en la página de Cisco sobre el producto (pdf).

¿Algún lector conoce un vehículo similar con tecnología de otro fabricante?

Generalmente, cuando administramos switches Cisco, es fácil encontrarnos con configuraciones idénticas en distintas interfaces de red. La forma habitual de configurar las interfaces, aunque sencilla, puede resultar tediosa, puesto que se trata de copiar la misma configuracion en distintas interfaces individuales o rangos de interfaces. No obstante, una forma más cómoda de hacerlo es mediante el uso de macros smartport.

Los macros Smartport son scripts de configuraciones creados previamente, que es posible aplicarlos a las distintas interfaces de red, de forma que ganamos consistencia y velocidad a la hora de configurar dispositivos.

Los Switches Cisco tienen varias macros creadas por defecto, que nos permiten configurar interfaces para soportar entre otros, equipos de usuario, telefonos, u otra electronica de red; mediante el comando show parser macro brief es posible ver las macros definidas en nuestro switch:

Switch#show  parser macro  brief
    default global   : cisco-global
    default interface: cisco-desktop
    default interface: cisco-phone
    default interface: cisco-switch
    default interface: cisco-router
    default interface: cisco-wireless

Al hablar de seguridad siempre la consideramos como un proceso en lugar de como un producto, puesto que cada día aparecen nuevas vulnerabilidades y amenazas. Debido a éste proceso continuo, un aspecto crítico es la formación del personal que gestiona cualquier ambito de la seguridad.

Habitualmente, la formación en materia de seguridad (sin entrar en la autoformación), se lleva a cabo mediante cursos o certificaciones, ya sean técnicas o no. Una de las certificaciones mas valoradas (o al menos más solicitadas) es la certificacion CISSP (Certified Information Systems Security Professional) ofrecida por ISC(2) (International Information Systems Security Certification Consortium).

Como vimos hace tiempo en el post sobre Checkpoint SYN Defender, cada vez es mas habitual encontrar fabricantes que añaden funcionalidad para mitigar algunos ataques de denegación de servicio en sus dispositivos de seguridad. En la ocasión anterior nos centramos en la solución SynDefender de Checkpoint y en esta ocasión, será en la característica TCP Intercept de los dispositivos routers de Cisco.

Como su nombre bien indica, Cisco TCP Intercept Feature es una característica de seguridad capaz de proteger y mitigar posibles ataques DoS basados en inundaciones TCP SYN contra nuestros servidores, monitorizando para ello el numero de intentos de conexión y en caso de ser necesario, reducir el número de conexiones TCP incompletas.

Hace algo mas de un año, uno de nuestros colaboradores escribió el post titulado “Disponibilidad en los servicios de conectividad a internet” donde se hacía referencia al secuestro de los prefijos IP de youtube desde Pakistan Telecom (junto otros ejemplos).

Copiando de dicho post, el ejemplo fue el siguiente:

Como sabrán, la semana pasada se celebró el IX Foro de Seguridad de Rediris en la Universidad Politécnica de Valencia, que ya presentamos en otra entrada con el lema “Seguridad en el Cloud Computing”, en las que S2 Grupo ha participado tanto como organizador como ponente. Este es un pequeño resumen de lo visto estas dos jornadas:

Sobrevolando el cloud computing. Seguridad y cumplimiento normativo.

Ramón Martín (Cloud Security Alliance, Autoritat Catalana de Protecció de Dades) nos hizo una breve introducción al Cloud Computing, enfocando las cuestiones relevantes en materia de seguridad de la información y definiéndolo como un modelo evolutivo de prestación de servicios, potenciado por distintos factores entre los que encontramos la conjunción de distintas tecnologías (virtualización, velocidad de acceso, uso dispositivos móviles), socialización de las tecnologías con un uso intensivo por parte de los usuarios y como casi siempre, la cuestión económica. Ramón nos mostró la arquitectura del cloud basada en componentes: características esenciales del servicio (acceso a red, velocidad, elasticidad), modelos de servicio (Saas, Paas, Iaas) y modelo de despliegue (publico, privado, publico, híbrido, comunitario) junto con distintas gráficas de beneficios, amenazas y retos existentes en el cloud.

La presentación está disponible para su descarga en la página del evento: descargar (PDF, 10.6MB)