Security Art Work

El encubrimiento de canales o Covert Channels es una técnica de evasión que permite a un atacante enviar información empleando para ello las cabeceras de los protocolos de comunicación. En esta entrada trataremos el encubrimiento de canales en el protocolo TCP/IP, y proporcionaremos una herramienta, CovertShell, diseñada para la prueba de concepto. Pueden localizar los fuentes al final de la entrada.

El protocolo TCP/IP presenta una serie de cabeceras que normalmente son inicializadas por el cliente para mantener o numerar una comunicación. La técnica covert channels aprovecha dichos campos para asignarle valores de tal forma que la máquina destino interprete dichos campos no como una forma de mantener una comunicación o aportar información sobre ésta, sino para obtener datos.

Un ejemplo interesante fue desarrollado por Craig H. Rowland en su paper de 1996: Covert Channels in the TCP/IP protocol Suite, donde éste creaba una pequeña herramienta cliente/servidor “CovertTCP” de no mas de 500 líneas que permitía la transferencia de ficheros entre cliente/servidor empleando para ello únicamente los campos SEQ, ACK del protocolo TCP y el campo ID del protocolo IP. De esta forma la información iba en las cabeceras de los protocolos y no en el contenido del paquete o payload.

A raíz de esta idea, siempre se ha pensado en la posibilidad de ir más allá y usar esta técnica para el envío de ordenes de comando. Algo que podría ser usado tanto para puertas traseras (backdoors) como para redes botnet. Imagínense que tenemos un servidor que ha sido comprometido al cual se le ha instalado un servicio que espera paquetes en un cierto puerto con cierto valores en su cabecera. Cuando le llega un paquete que cumple esos requisitos, procesa los valores de las cabeceras convirtiendo dichos valores en ordenes de comando, que son posteriormente ejecutadas.

Siguiendo este modelo hemos creado una pequeña herramienta para la prueba de concepto a raíz del código fuente del CovertTCP, denominada CovertShell, donde disponemos de un servicio que emplea un socket RAW de tal forma que al recibir en el puerto indicado paquetes con el bit ACK y sin el bit SYN, obtiene el identificador de la cabecera IP, el cual es el número identificativo correspondiente a una letra en código ASCII. Dicha letra es almacenada en un vector. Cuando llegan 3 paquetes cuyo ID es 255, el servidor ejecuta la orden de comando que hay almacenada en el vector. Por tanto disponemos de un servidor que no abre ningún puerto, que realmente escucha el tráfico y que es capaz de interpretar la cabecera IP para generar comandos. Dicho de otra forma, tenemos una puerta trasera empleando covert channels para comunicarse. ¿Lioso? Veamos un ejemplo de funcionamiento:

Compilamos y ejecutamos el servicio que espere paquetes en el puerto 8888 en la máquina víctima (servidor):

# gcc servidor.c -o servidor 
# ./servidor -port 8888

En otra consola comprobamos que el proceso está levantado y que no hay ningún servicio escuchando en el puerto 8888:

# ps aux | grep servidor | grep -v grep 
root      2465  0.0  0.0   3908   312 pts/0    S+   09:53   0:00 ./servidor -port 8888 
# netstat -putan | grep 8888 
# lsof -Pi | grep 8888

A continuación vamos a emplear un pequeño script en bash, agradecer la ayuda a Raúl Rodriguez (no te escondas), que requiere tener instalado el binario Nemesis (permite manipular paquetes de forma sencilla). A dicho script le pasamos una orden entre comillas, de tal forma que generará un paquete por cada letra, donde el valor ID del campo IP, será el valor ASCII de la letra indicada.

Dentro del script tenemos la variable IP_DST y DPORT donde hay que indicar la IP y puerto de nuestro servidor víctima. También tenemos las variables IP_ORIGEN y SPORT donde se indica la IP y Puerto origen (puede ser cualquiera). Para el POC vamos a indicar a Nemesis que la dirección IP de origen es la de un servidor de Google y el puerto origen es el 80. De esta forma al servidor víctima le llegarán paquetes con el flag ACK con IP origen de Google y el puerto 80.

De este modo, si leemos la traza de red veremos únicamente que están llegando paquetes ACK de google, algo de lo más normal, cuando realmente lo que nos está llegando son comandos de una backdoor.

Para esta demo vamos a crear el usuario “ximo” (que me han dicho que es muy peligroso) en la máquina víctima:

Cliente:

# ./cliente.sh "useradd ximo" 
TCP Packet Injected 
TCP Packet Injected 
TCP Packet Injected 
TCP Packet Injected 
TCP Packet Injected 
TCP Packet Injected 
TCP Packet Injected 
TCP Packet Injected 
TCP Packet Injected 
TCP Packet Injected 
TCP Packet Injected 
TCP Packet Injected 
TCP Packet Injected 
TCP Packet Injected 
TCP Packet Injected 
# 

Servidor:

# ./servidor -port 8888 
Dato recibido: 117 
Dato recibido: 115 
Dato recibido: 101 
Dato recibido: 114 
Dato recibido: 97 
Dato recibido: 100 
Dato recibido: 100 
Dato recibido: 32 
Dato recibido: 120 
Dato recibido: 105 
Dato recibido: 109 
Dato recibido: 111 
Comando: useradd ximo

¿Habrá funcionado?

# tail -1 /etc/passwd 
ximo:x:1002:1002::/home/ximo:/bin/sh 
# 

Ahora vamos a ver la traza de red desde el servidor (IP 172.17.X.X) cuando se ha enviado el comando “useradd ximo”. En este caso recordar que hemos usado la IP de Google, por lo que la IP origen usada es “66.249.92.104” obtenida de un simple ping:

$ ping -c1 google.es
PING google.es (66.249.92.104) 56(84) bytes of data.

Veamos la traza:

# tcpdump -nn -vvv -i eth0 port 8888 
10:00:55.265912 IP (tos 0x0, ttl 254, id 117, offset 0, flags [none], proto TCP (6), 
    length 40) 
    66.249.92.104.80 > 172.17.X.X.8888: Flags [.], cksum 0x2912 (correct), 
    seq 283280788, ack 1457724121, win 4096, length 0 
10:00:55.265964 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 
    172.17.X.X.8888 > 66.249.92.104.80: Flags [R], cksum 0xcf94 (correct), seq 
    1457724121, win 0, length 0 
10:00:55.270636 IP (tos 0x0, ttl 254, id 115, offset 0, flags [none], proto TCP (6), 
    length 40) 
    66.249.92.104.80 > 172.17.X.X.8888: Flags [.], cksum 0x2909 (correct), seq 
    1069023501, ack 78166684, win 4096, length 0 
10:00:55.270669 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 
    172.17.X.X.8888 > 66.249.92.104.80: Flags [R], cksum 0x1051 (correct), seq 
    1535890804, win 0, length 0 
10:00:55.280132 IP (tos 0x0, ttl 254, id 101, offset 0, flags [none], proto TCP (6), 
    length 40) 
    66.249.92.104.80 > 172.17.X.X.8888: Flags [.], cksum 0x827f (correct), seq 
    1249543965, ack 4145208809, win 4096, length 0 
10:00:55.280157 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 
    172.17.X.X.8888 > 66.249.92.104.80: Flags [R], cksum 0xfa99 (correct), seq 
    1307965633, win 0, length 0 
10:00:55.284502 IP (tos 0x0, ttl 254, id 114, offset 0, flags [none], proto TCP (6), 
    length 40) 
    66.249.92.104.80 > 172.17.X.X.8888: Flags [.], cksum 0x5a89 (correct), seq 
    4108084880, ack 626806209, win 4096, length 0

Al servidor nos han llegado una serie de paquetes TCP con flag ACK ([.]) desde la IP de Google (66.249.92.104), con puerto origen 80 sin payload, al cual hemos respondido con un paquete RST. Si nos fijamos en los paquetes de envío veremos el campo “id número”, que identifica el valor del campo id del protocolo IP, el cual tiene valores como 117, 115, 101, 104, … que corresponden con los valores ASCII de u, s, e, r, …

Como podréis suponer, la posibilidad de rastrear ese comando es realmente compleja puesto que en ningún momento nos llega la IP del atacante ya que se falsifica la IP origen.

Pero vayamos más allá: ¿qué ocurriría si en vez de jugar con la cabecera ID del protocolo IP, usáramos el valor de secuencia (SEQ) del paquete TCP, de tal forma que enviáramos un paquete TCP con flag SYN (inicio de conexión) a un servidor público cuya IP y puerto origen sea la de la víctima? Pues que el servidor público contestaría a la víctima con un paquete SYN ACK al puerto indicado como puerto origen, cuyo valor ACK corresponderá al valor de sesión enviado por el atacante + 1. Por tanto se podría usar servidores públicos legítimos para que mandaran en la cabecera TCP la orden a ejecutar, siendo todavía más difícil rastrear quien ejecutó la orden. Veamos una imagen que aclara esta idea:

Esto último, así como posteriores pruebas, quedan como ejercicio para el lector. Los desarrollos realizados para la prueba de concepto, que hemos denominado CovertShell, están a disposición del público. Esperamos que les sea de ayuda, sin olvidar por supuesto que se ponen a disposición del público para fines educativos y de investigación.

La entrada de hoy martes es una colaboración de Javier Cao, un “clásico” del sector que no requiere demasiadas presentaciones. Para aquellos que no lo conozcan, Javier Cao es Ingeniero en Informática por la Universidad de Murcia, certificado CISA y posee los certificados de los cursos IRCA ISO 27001 e IRCA ISO 20000.

Esperamos que les guste la entrada.

En el momento actual de inicio y expansión de sistemas de gestión de la seguridad de la información (en adelante SGSI), la principal preocupación es naturalmente lograr la construcción y establecer bien los procesos que permitan lograr construir el ciclo de mejora continua y certificar el sistema.

Sin embargo, conforme vayan pasando los años estos sistemas deben ir madurando para lograr verdaderamente satisfacer los objetivos establecidos por la Dirección. Uno de los grandes beneficios de implantar un sistema de gestión basado en ISO 27001 debe ser pasar de una “seguridad basada en sensaciones” a una “seguridad basada en datos de comportamiento” que permita mostrar y sobre todo, demostrar que las cosas se están controlando y se mantienen dentro de unos rangos de valores aceptables.

En este sentido, los criterios de gestión establecidos por la Dirección y que debieran estar referenciados en la Política de Seguridad de la Entidad, son el marco de trabajo para todas las personas involucradas de forma activa o pasiva, dentro de las actividades de operación, mantenimiento y supervisión del SGSI. Estas directrices generales son tanto el rumbo como las metas que el sistema de gestión debe lograr. Todo el esfuerzo de construcción y mantenimiento de un SGSI no se justifica si con ello no se logran determinados resultados; un SGSI tiene costes y por tanto, debe ser amortizado y rentabilizado lo máximo posible. Esto, dentro del ámbito de la seguridad, supone que las cosas deben funcionar con normalidad y los imprevistos, incidentes o accidentes deberán ser gestionados de forma correcta para minimizar los daños que pudieran producirse. Pero para lograr esto, es necesario justificar y demostrar con datos todo el esfuerzo que es necesario realizar para que las medidas de seguridad funcionen cuando hagan falta.

Partiendo de la célebre frase de Lord Kelvin (1824-1907), “Lo que no se define no se puede medir. Lo que no se mide, no se puede mejorar. Lo que no se mejora, se degrada siempre“, un SGSI debe tener establecidos criterios de medición de la eficacia y la eficiencia como así establece la propia normativa en las cláusulas 4.2.2. Apartado e) y 4.2.3. Apartado b).

Para ilustrar esta faceta de la seguridad y como viene siendo tradicional dentro del blog “Security Art Work” voy a utilizar como símil de un buen modelo de seguridad la Fórmula 1 dado que creo se comparte un gran paralelismo en los enfoques de ambos mundos.

[Read more…]

A principios de agosto se hizo público que la CMT (Comisión del Mercado de las Telecomunicaciones) disponía de un nuevo servicio por el que los usuarios pueden conocer el operador asociado a un número de teléfono móvil en el ámbito español.

En los principios de la telefonía móvil bastaba con identificar los primeros dígitos de un teléfono móvil para saber el operador al que estaba asociado un número. Si no recuerdo mal, los que empezaban por 654 eran de Amena (ahora Orange), y los que empezaban por 607 o 610 de la antigua Airtel (ahora Vodafone). Pero actualmente, con el auge de los OMV (Operadores Móviles Virtuales) se ha facilitado el proceso y se ha convertido en usual cambiar un número de móvil de una compañía a otra, para intentar ahorrar al máximo en la factura de nuestro móvil, lo que hace muy difícil seguir la pista de los operadores asociados a nuestros móviles.

A primera vista, este servicio puede tener sus ventajas, puesto que visto desde la óptica de un usuario de a pie nos permite conocer el operador móvil de nuestros contactos para ahorrar en nuestras facturas. Es de sobra sabido que las llamadas entre teléfonos de la misma compañía siempre es más barato, así que este podría ser un buen método para decidir a quién llamar primero. Sin embargo, me muestro reticente a considerar este un servicio cuyo uso se vaya a generalizar entre los usuarios, y también se producía en mi interior cierto aire de desconfianza, porque viéndolo desde la óptica de un operador móvil (o una persona que se quiera hacer pasar por él), este servicio puede permitir a ese operador o persona malintencionada conocer la compañía que me presta servicio y ejecutar, entre otros, acciones comerciales no deseadas contra mí.

Según parece, los datos que ofrece esta web son de carácter público y no se está incurriendo en ninguna ilegalidad al divulgarlos públicamente cuando van disociados de sus propietarios como es el caso. Pero a pesar de ello, la necesidad de identificarnos para poder comprar un número de teléfono o utilizar uno existente y la tan manida LOPD (Ley Orgánica de Protección de Datos), con la eterna disputa sobre si el teléfono móvil es un dato personal o no, me hacen ver con cierto recelo esta nueva plataforma y su utilidad de cara al ciudadano “de a pie”.

¿Qué opinan ustedes? ¿Creen que es una plataforma útil para el usuario, o por el contrario genera más problemas que ventajas?

El teléfono móvil SÍ es un dato personal:
http://www.eldia.es/blogs/el13devalentinsanz/?p=478
http://www.iurismatica.com/blog/el-numero-de-telefono-movil-es-un-dato-de-caracter-personal/
http://www.samuelparra.com/2009/01/29/consecuencias-de-no-considerar-el-numero-de-telefono-movil-como-dato-personal/

El teléfono móvil NO es un dato personal:
http://www.carlosucelay.com/index.php?option=com_content&view=article&id=19

Acceso al portal:

https://numeracionyoperadores.cnmc.es/portabilidad-movil/operador

Los sistemas de detección de intrusos (IDS) son sistemas que requieren un ajuste adecuado para evitar falsos positivos, falsos negativos, alertas repetitivas que colapsan la consola de operación etc. Cuando se decide implantar un IDS, como parte del proceso de implantación, se requiere haber diseñado una batería de pruebas para comprobar que lo implantado reacciona adecuadamente y poder tener una cierta garantía (garantía total es imposible debido a la heterogeneidad del tráfico que circula por las redes) de poseer un ajuste fino y con buen rendimiento. En esta entrada vamos a hablar de la herramienta Rule2alert [1], que nos ayudará a crear una batería de pruebas propia, con el fin de realizar el mejor ajuste posible de nuestros IDS.

Rule2alert, como se puede leer en la página oficial del proyecto, [1] toma como entrada reglas de Snort y genera tráfico de red a partir de ellas, pudiéndolo volcar a un fichero con formato pcap. Rule2alert es una herramienta que se basa en otra herramienta llamada Scapy[2], en la cual destaca su potencia para la manipulación de paquetes de red.

Vista la descripción, vamos a hacer una pequeña prueba a ver que tal se comporta la herramienta. Cabe mencionar que hemos realizado las pruebas sobre un sistema GNU/Linux Debian Testing.

Lo primero, descargamos la aplicación de una manera rápida (no hemos encontrado un tar.gz/zip disponible a la fecha de escritura de esta entrada) mediante wget:

Una vez descargada, dentro del directorio “rule2alert.googlecode.com/svn/trunk” dispondremos de la aplicación r2a.py. Para comprobar que tenemos todas las dependencias (comentar que con la versión 2.5.2 de Python no nos funcionaba correctamente, en cambio, con la versión 2.6 no hay problema) y las versiones adecuadas, ejecutamos:

Para hacer las pruebas construimos un fichero test.rule con la siguiente regla:

En este instante, disponemos un fichero pcap de nombre test.pcap que, al abrirlo con Wireshark, podremos ver como ha generado el fichero:

Por lo que hemos podido comprobar, con Rule2alert generamos tráfico que va a encajar en nuestro IDS y debe generar una alerta, por lo que podemos realizar pruebas sobre nuestra configuración. Para probar este tráfico sobre el IDS, la manera más sencilla y rápida sería como nos indican en el propio Wiki de la herramienta:

A continuación, planteamos dos posibles ejemplos de pruebas (de los trillones de posibilidades) a realizar con la herramienta:

• Una primera prueba sería inyectar “n” alertas iguales sobre nuestro IDS, de manera que probemos los umbrales de nuestras reglas (threshold, etc.). Si se da el caso de que disponemos de un correlador que recoge nuestras alertas del IDS, con esta prueba podemos comprobar que las reglas de correlación están haciendo su trabajo; resolviendo incógnitas como “¿agregará bien las alertas?”, “¿dispara un evento de criticidad superior?”, “¿me envía el correo y además un SMS?, etc.
• Como bien sabéis, existen ocasiones en las que es necesario establecer filtros para determinado tipo de tráfico de red, debido a falsos positivos donde el tráfico es totalmente legítimo. En este caso puede ser interesante, para comprobar que no nos hemos pasado filtrando, lanzar una prueba con un paquete que sabemos que debe saltar alerta y otra donde no tendría que saltar. Siempre es mejor prevenir que curar :).

Queda claro que cualquier aspecto de la configuración de Snort es posible contrastarlo con Rule2alert, de manera que podamos afinar un poco más nuestra configuración. Esperamos que les resulte de utilidad la herramienta :).

[1] http://code.google.com/p/rule2alert/
[2] http://www.secdev.org/projects/scapy/

Hace relativamente poco, buscando algún entretenimiento que me ayudara a salir de la rutina y estando fuertemente influenciado por mi pareja, decidí apuntarme a una actividad que ha resultado ser de lo más divertida: bailar Rock. ¡No me refiero a salir de marcha por locales! Estoy hablando de asistir a clases de baile. Acotando un poco más os diré que bailamos música swing de entre los años 1920 y 1950. Existen distintos estilos de baile relacionados con la música swing: Boogie Woogie, Lindy Hop, Rock´n´Roll, Balboa,… Las clases a las que asisto se centran principalmente en el estilo Lindy Hop.

Para situaros en escena y sin querer entrar en mucho detalle os diré que el Lindy Hop es un estilo de baile popularizado en Nueva York por bailarines afro-americanos en una sala de baile llamada Savoy Ballroom. El baile tenía como base el Charlestón pero incorporaba elementos de otros estilos como el “Texas Tommy“, el “Black Bottom” y el “Cakewalk“. El Lindy Hop nació cuando estos bailarines empezaron a incorporar posiciones abiertas intercalándolas con las tradicionales posiciones cerradas. En la práctica, se trata de un baile rápido, enérgico y, desde mi punto de vista, bastante divertido. El baile puede enriquecerse con una gran variedad de acrobacias que serán más o menos espectaculares en función de la experiencia y de la forma física de los bailarines.

En lo referente a las lecciones de baile puedo decir que las primeras han sido más bien “introductorias”, lo cual era previsible pues la mayoría de asistentes desconocíamos por completo el estilo de baile. No obstante, he de decir que también acuden algunas parejas experimentadas que ensayan coreografías relativamente complejas.

[Read more…]

Como vimos en el anterior post, la manera habitual analizar el tráfico de nuestra red pasa por configurar la interfaz de uno de nuestros switches en modo SPAN (o R-SPAN) y reenviar el tráfico para su posterior análisis mediante un analizador de red o un IDS.

Aunque esta solución suele ser la habitual, y suficiente en la mayoría de casos, presenta una serie de problemas, como pueden ser la limitación del número de interfaces (o VLANs) que podemos configurar en modo SPAN, y la carga de CPU asociada a la captura y envío del tráfico, incluyendo la carga generada al propio analizador de red, puesto que recibe todo el tráfico que atraviesa la interfaz, sea interesante o no para nuestra captura.

[Read more…]

Como ayer apuntaba José Luis, estuvimos presentes en el congreso de ISACA Valencia 2010, realizado los días 19 y 20 de octubre en la Universidad Politécnica de Valencia. La sesión de ayer miércoles, dedicada a la e-Administración, comenzó con un par de ponencias dedicadas la primera de ellas al estado general de la administración electrónica en España, a cargo de Lorenzo Cotino (Universidad de Valencia), y la segunda a la interoperabilidad, a cargo esta de Roberto Santos, de Telefónica -o Movistar- (videoconferencia desde León con algún que otro problemilla técnico que finalmente pudo subsanarse).

Tras un café, continuó la jornada con una excelente ponencia de Manuel Caño (LBIGroup) en la que se desgranó de una forma muy clara la necesidad de la contratación electrónica para todos (AAPP, empresas…), los problemas a los que se enfrenta en la actualidad y las líneas de resolución que se están adoptando a nivel europeo -que pasan todas por la estandarización-. Tras Manuel, se formó una mesa redonda en la que participaron José Benedito (Diputación de Valencia), Mar Ibáñez (ACCV, en representación de la Generalitat Valenciana) y Ramón Ferri (Ayuntamiento de Valencia), y en la que se plantearon trabajos, problemas y reflexiones en torno a la e-Administración desde el punto de vista de la propia administración pública. Tengo que decir una vez más que lo que yo entendía por “mesa redonda” sigue sin coincidir con lo que entiende el resto del mundo, porque las mesas redondas que llevo viendo desde hace unos años se limitan simplemente a presentaciones más cortas que el resto de las expuestas en el congreso; pero salvado este detalle, decir que me gustaron especialmente las reflexiones personales de José Benedito a la hora de plantearse qué requiere un ciudadano de la administración (hablando de trámites administrativos, no asistenciales -sanidad, educación…-) y dejando en el aire si realmente hace falta todo lo que tratamos de hacer. A fin de cuentas, el 90% de los ciudadanos tenemos unas comunicaciones con las AAPP muy simples: declaración de la renta con AEAT, algunos impuestos con el ayuntamiento y poco más… ¿no estaremos matando moscas a cañonazos con tanta e-administración? Ahí queda eso :)

Para finalizar, decir que este año, para mi sorpresa, la afluencia de público al congreso ha sido mínima, tanto el primer día como el segundo (el último día había un poquito más de gente, pero nada perceptible). Comparado con el éxito de asistencia del congreso 2009, este año nos hemos llevado un chafón; confiemos en que 2011 sea mejor…

P.D. Aquí teneis la presentación con la que S2 Grupo participó en el congreso. Disfrutadla :)

No, no estamos hablando de dejar esta vida ajetreada de las ciudades e irnos al campo a vivir y alimentarnos de lo que cultivamos y criamos. Tampoco hablamos de “invertir” nuestro tiempo libre en juegos de una determinada red social para aprender las labores del campo. Este post viene a explicar el proceso que hemos seguido para optimizar el rendimiento de un sistema de detección de intrusos (IDS) en redes con una tasa de tráfico alta.

Hace tiempo se nos propuso preparar para un cliente un sistema de detección de intrusos de alto rendimiento, capaz de procesar una gran cantidad de tráfico totalmente heterogéneo. Así que preparamos una máquina con muy buenas prestaciones para asegurarnos que, por hardware, no iba a ser; a saber, un procesador de 6 cores con 4 GB de memoria RAM, tarjetas Gigabit Ethernet y un sistema NAS para albergar toda la información generada en una red que, suponíamos, iba a ser muy complicada de manejar por la cantidad, la variedad y la naturaleza de su tráfico.

Se optó por una de las soluciones más extendidas en los sistemas de detección de intrusos de código abierto: Snort.

[Read more…]

Durante el día de ayer y hoy, se celebra en la Universidad Politécnica de Valencia el congreso ISACA Valencia 2010 organizado por el capítulo de Valencia de ISACA, que lleva como título “Esquema Nacional de Seguridad e Interoperabilidad y e-Administración”. Durante la jornada de ayer se realizaron una serie de conferencias dentro del marco del Esquema Nacional de Interoperabilidad y Seguridad, en las que S2 Grupo participó como ponente, y de las cuales, procedemos a realizar un pequeño resumen introductorio a continuación.

Protección de Marca

Nuestro compañero Antonio Villalón (S2 Grupo) planteó diversas cuestiones relativas a la reputación, tanto a nivel personal como a nivel de empresa, reflexionando acerca de los problemas actuales, los mismos que hace años pero elevados a la enésima potencia, debido al acceso global a la información donde todo el mundo puede opinar (en ocasiones amparados por una sensación de anonimato en la red), y recalcando que mi reputación no es algo que dependa únicamente de mí. Esta situación ha generado nuevos patrones de ataque no sólo sintácticos (virus, DoS, troyanos, etc), sino también semánticos (daño por la interpretación de la información que hace el ser humano). Para acabar, Toni nos ha sugerido que busquemos nuestro nombre en Internet para ver qué información existe de nosotros.

[Read more…]

Hace ya unos años que se produjo el boom de ventas de novelas históricas y ambientadas en el medievo. Quizás el máximo exponente fueron los famosos “Pilares de la Tierra” de Ken Follet que, aunque se publicó en 1989, creo que no ha habido ninguna novela posterior de este género que la haya podido destronar. De hecho recientemente también ha servido para poner “de moda” las series históricas de TV, con la adaptación producida por Ridley Scott. En 2007 la novela de Follet tuvo su continuación con “Un mundo sin fin”, novela que continúa la trama con los descendientes de los protagonistas de los Pilares.

Y ustedes dirán: ¿y este hombre qué nos está contando? Que esto es un blog de seguridad…

Pues les voy a sorprender. Esto es como la teoría de los grados de separación, que dice que entre dos personas que no se conocen en el mundo hay una cadena de conocidos de no más de cinco personas, y por tanto seis saltos.

Voy a ello. Para escribir la segunda parte de los Pilares (por cierto, felicidades a las Pilares que lean este blog por su reciente santo), Ken Follet se inspiró en las obras de restauración de la Catedral de Santa María de Vitoria-Gasteiz, ciudad que me permito recomendarles, y que tuve el placer de disfrutar en mis primeros años en esto de la seguridad (allá por el año 2000), colaborando en un proyecto para la Diputación Foral de Álava. De hecho, la ciudad, en la que se hizo la presentación mundial del libro, ha honrado al escritor británico con una estatua de bronce en su honor.

[Read more…]