BlackBerry (in)security?

Durante las últimas semanas se ha venido hablando acerca de la “adicción” del presidente electo de los Estados Unidos, Barack Obama, a su BlackBerry, y la negativa de la NSA (National Security Agency) a que siga utilizándola durante su mandato; según se ha publicado, parece que Obama llegó a declarar que le tendrían que arrancar su BlackBerry de las manos -imagino que en tono coloquial, dicho sea de paso-, ya que el servicio secreto de los Estados Unidos considera inseguras las comunicaciones realizadas mediante BlackBerry.

El de Obama no es el único caso en el que el uso de estos dispositivos se prohíbe de forma tajante a aquellos que puedan manejar información altamente confidencial; hace algo menos de dos años, el gobierno francés prohibió también a sus altos funcionarios el uso de BlackBerries, por el mismo motivo (un tema del que también se hicieron eco muchos medios). Pero… ¿es esta medida justificada, o por el contrario podemos considerarla desproporcionada?

Bajo mi punto de vista -ojo, y no soy ni de lejos un experto en la seguridad de BlackBerry-, cuando la NSA suena, agua lleva; dicho de otra forma: si el presidente no puede utilizarla por motivos de seguridad, por algo será. Pero de ahí a considerar la seguridad de BlackBerry como algo prohibitivo para el resto de mortales -que por suerte o desgracia no solemos manejar información crítica para la estabilidad mundial- hay un abismo; configurando adecuadamente diferentes parámetros del dispositivo, se puede conseguir un nivel de seguridad más que aceptable para el 99.999% de las personas que lo usan.

Así, el hecho de que Obama no pueda manejar su BlackBerry por motivos de seguridad, no implica que el resto del mundo deba hacer lo mismo; al final, como siempre, se trata de una cuestión de riesgos a asumir: el servicio secreto no asume ese riesgo en el caso de comunicaciones secretas, lo que no implica ni de lejos que el Departamento de Seguridad de la mayoría de organizaciones deba recomendar no asumirlo. Especialmente, si tenemos en cuenta las necesidades de movilidad del negocio, y las alternativas a BlackBerry que existen en la actualidad; una de ellas, aprobada oficialmente por la NSA para transmisión de datos clasificados, es Sectera Edge, de General Dynamics. Eso sí, preparemos una buena cantidad de dólares (o de euros) si queremos comprarla: casi 3.000 euros por unidad… Como casi siempre, una cuestión de dinero.

Si como consultor me preguntaran acerca de la seguridad de BlackBerry para las comunicaciones de Barack Obama, seguramente recomendaría no utilizar este dispositivo; si me preguntaran acerca de la seguridad de BlackBerry para las comunicaciones del Director General de Plásticos Cremallera o Piruletas de Motilla del Palancar, probablemente recomendaría su uso siempre que se apliquen las medidas de seguridad habituales (configuración correcta, actualización, etc.). Seguramente, la competencia de ninguna de estas dos empresas tiene la capacidad ni los recursos para interceptar y descifrar las comunicaciones de ambos directores generales.

¿Cómo determinar si el uso de BlackBerry es un riesgo inaceptable para nuestra organización, o si por el contrario vale la pena asumirlo y no aplicar alternativas tan caras? Sin duda, podríamos hablar de análisis de riesgos, estudios, estadísticas… para llegar a una u otra conclusión, pero en este caso, y siempre IMHO, hay una primera aproximación muy útil: si una persona necesita más de dos guardaespaldas de forma simultánea, quizás debamos plantearnos alternativas a BlackBerry. Otro ejemplo de convergencia de la seguridad :)

Seguridad contra Aceptabilidad

La aceptabilidad de un determinado control es un factor crítico cuando hablamos de implantar salvaguardas en nuestras organizaciones. No nos engañemos: podemos implantar la mejor política perimetral en el mejor cortafuegos, el pasillo mecanizado más moderno, la política de contraseñas más robusta… si los usuarios no las aceptan, estas medidas fracasarán antes o después: los usuarios acabarán con tarjetas 3G conectando desde sus portátiles a Internet, el vigilante de seguridad abrirá el pasillo para que no se acumule gente en horas punta, y todos apuntarán sus contraseñas en postits.

Las medidas de seguridad más efectivas no suelen ser aquellas que sólo son técnicamente más avanzadas que el resto, sino que a esa eficacia -que se presupone- se debe unir un alto grado de aceptabilidad; hace años, estudiando acerca de sistemas de autenticación, leía un ejemplo muy significativo: quizás un modelo de autenticación rápido, barato y robusto podría basarse en un análisis de ADN o similar (me lo invento, por supuesto, no sé si analizar ADN en la actualidad es barato, rápido y robusto). Al acceder a una sala de acceso restringido, o a un sistema informático, podríamos sustituir las tarjetas inteligentes o las contraseñas por un simple análisis de sangre u orina del usuario, que en caso de ser satisfactorio abriría una puerta o una aplicación. Sencillo, ¿verdad? Probablemente, desde el punto de vista de seguridad, sería perfecto, pero el nivel de aceptabilidad haría que el sistema fracasara: poca gente está dispuesta a dar sangre para abrir una puerta, y tampoco a tener un botecito con la leyenda “Deposite aquí su muestra”.

La aceptabilidad de las medidas de seguridad es cada vez más crítica conforme la medida es invasiva o puede poner en riesgo -o parecer que pone en riesgo- la privacidad del usuario; en biometría encontramos los casos más claros: el análisis de huellas se asocia a criminales, el análisis de retina puede permitir la detección de enfermedades -aparte del miedo lógico a que un escáner nos barra el ojo-, etc. Modelos de autenticación biométrica técnicamente estupendos han fracasado debido a que los usuarios no aceptan el sistema, y por tanto evitan utilizarlo o tratan de engañarlo por cualquier medio.

De esta forma, es responsabilidad de los que trabajamos en seguridad el implantar controles no sólo técnicamente correctos, sino ACEPTABLES por parte de aquellos que tienen que vivir con ellas día a día. Es especialmente importante que nuestras medidas de seguridad sean aceptables cuando repercuten en el trabajo de los usuarios menos concienciados con la seguridad: si a un técnico le obligamos a utilizar contraseñas de veinte caracteres para entrar en un router, entenderá que se trata de una importante medida de seguridad, pero si obligamos a utilizar una clave igual de larga a alguien del departamento de Recursos Humanos para acceder a su correo electrónico, acabará apuntándola en cualquier sitio o utilizando contraseñas triviales.

Evidentemente, no podemos seleccionar nuestros controles de seguridad en base únicamente a la aceptabilidad que van a tener en la organización; si así fuera, seguramente no implantaríamos ninguna medida de seguridad y dejaríamos la protección del negocio al libre albedrío de los usuarios, aproximación que significaría desprotección total (o best effort, en el mejor de los casos). Como siempre, necesitamos un equilibrio entre seguridad y, en este caso, aceptabilidad; si logramos dicho equilibrio, podremos estar seguros de haber implantado una medida que funcionará correctamente y que se mantendrá en el tiempo, garantizando así la seguridad de nuestro negocio.

Seguridad contra Seguridad

Los que nos dedicamos a Seguridad siempre hemos oído (y asumido como propio) aquello del equilibrio entre seguridad y funcionalidad: debemos conseguir una seguridad aceptable para los procesos corporativos de nuestra organización, pero al mismo tiempo sin degradar el correcto funcionamiento de dichos procesos y permitiendo que el negocio continúe; y todo esto, por supuesto, en base a los recursos de los que dispongamos y a la estrategia corporativa. Dicho de otra forma, si mi seguridad se basa en mantener siempre los sistemas críticos apagados o las puertas de mi oficina comercial cerradas permanentemente, lo más probable es que sea el más seguro… de la cola del paro.

No obstante, conforme la seguridad se ha convertido en una materia multidisciplinar en las organizaciones, en las que ya no hablamos sólo de seguridad sino que ampliamos el concepto a protección del negocio, y tocamos ramas tan dispares (¿o no?) como la seguridad legal, la continuidad del negocio, la seguridad física o la seguridad lógica, nos encontramos con que en ocasiones no sólo debemos mantener el equilibrio del que hablábamos antes (seguridad vs. funcionalidad, seguridad vs. coste) sino que además debemos anteponer en ocasiones una visión de esa seguridad frente a otras.

Imaginemos que nuestra compañía organiza unas sesiones comerciales para presentar sus nuevos productos, sesiones a las que va a acudir algún que otro VIP. Cuando desde Seguridad se solicita a Protocolo la relación de personas que van a asistir, para determinar qué medidas de protección es necesario adoptar, Protocolo nos dice que por la LOPD no puede facilitarnos esta relación (o sí que puede, pero tardará N días, cuando la sesión es dentro de N-1 días). ¿Qué hacemos? Aparte de iniciar los trámites necesarios para que no vuelva a ocurrir, tenemos dos opciones: si queremos proteger adecuadamente a las personas que acuden al evento, debemos conseguir esa lista por algún medio, y si queremos cumplir con la ley, no podemos conseguirla… En cualquier caso, el problema tiene mala solución, ¿verdad?

A diario en nuestro trabajo podemos encontrar ejemplos como el anterior. Ya no sólo se trata de garantizar la seguridad global de la organización, sino que en ocasiones se trata de anteponer una visión de la seguridad a otras; como hemos dicho, los riesgos que debemos evaluar sobrepasan muchas veces el habitual “seguridad vs. funcionalidad”. Sólo un detalle: tengamos en cuenta que la protección de personas siempre suele ser el elemento más crítico en cualquier organización (por si sirve de pista para solucionar el problema anterior ;).

Ah, podemos enlazar esta entrada con la serie acerca de Problemas LOPD, en este mismo blog… ¿o no es lo mismo?

La norma ISO 28012:2008

Dentro de la familia de normas ISO 28000, relativas a seguridad en la cadena de suministro, y de especial relevancia en el tema de protección de infraestructuras críticas nacionales que ya hemos comentado en algún post dentro de este mismo blog, ISO acaba de publicar la norma ISO 28012:2008, Metodologías para el Análisis de Riesgos en la Cadena de Suministro Portuaria.

Esta norma, no certificable -para eso está ISO 28001-, define como su nombre indica los métodos a seguir para realizar un análisis de riesgos focalizado en el suministro a través de puertos. Para ello, define una clasificación de activos muy distinta a lo que hasta ahora conocíamos (por ejemplo, a través de MAGERIT), y es que la norma se basa no en lo que los activos son (sistemas, información, personas…), sino en lo que los activos valen para la organización (algo completamente coherente, dicho sea de paso). Así, tanto los impactos sobre el negocio de la pérdida o degradación de un activo se calculan en base a esta premisa, y por tanto el riesgo que la organización soporta viene directamente derivado del valor de cada activo concreto para el negocio.

ISO 28012:2008 clasifica el valor de los activos en cinco niveles, del 1 (valor más bajo) al 5 (máximo valor), y determina los riesgos para el negocio en base a esos valores. Por tanto, un activo de valor 1 puede degradarse -o perderse- por una amenaza determinada sin que el impacto asociado cause daño en la organización, mientras que esa misma amenaza sobre un activo de valor 5 constituye un riesgo no asumible y que por tanto debe ser mitigado.

Realmente, esta aproximación es similar en resultados a la aproximación clásica de cualquier metodología de análisis de riesgos; lo realmente curioso es que al valorar los activos -de todo tipo-, la norma establece valores de mercancías transportadas en barco (en base al precio global del contenedor y del impacto de su pérdida), pero también establece “valores” para otros activos relevantes en la cadena de suministro, como son las personas encargadas de garantizar que dicha cadena es correcta y completa.

Sin entrar a juzgar la ética de valorar a las personas con un determinado nivel, y considerar su pérdida como algo asumible o no para el negocio, hemos realizado un “simulacro” de análisis según esta norma, y siguiendo sus indicaciones al pie de la letra podemos determinar que las personas más prescindibles para la cadena de suministro portuario son los keypiggers, una figura hasta ahora considerada clave en cualquier autoridad portuaria y cuyo cometido es registrar por triplicado las entradas y salidas de mercancías, buques y personas al recinto portuario. Y realmente, fijándonos con un poco de atención en las funciones de dicha figura, podemos determinar que desde hace años está realizando un trabajo completamente redundante, ya que el control de contenedores y buques se realiza de forma automática en cualquier puerto moderno, mediante tecnologías como RFID, mientras que el control de personas se realiza a través de la Policía Portuaria, que tiene delegada dicha función por Real Decreto desde 1.966.

De esta forma, algo tan sencillo como la publicación -y aplicación- de una norma de seguridad, va a ahorrar a los puertos de todo el mundo una enorme cantidad de dinero, simplemente prescindiendo de la figura del keypigger, considerada clave hasta el momento y que se ha demostrado poco o nada relevante en la realidad (y que por tanto, con toda probabilidad, va a ser la figura a desestimar en cualquier puerto). Y lo más sorprendente es que, después del keypigger, seguramente vendrán más.

Como vemos, esta norma ha entrado muy fuerte en el panorama de la seguridad, ya que su publicación y aplicación ha detectado de forma directa un gasto sin sentido desde hace años y cuya anulación va a suponer a las autoridades portuarias de todo el mundo un gran ahorro. Esto demuestra, una vez más, dos cosas: por un lado, la enorme utilidad de una norma bien aplicada, y por otro, el grado de pasividad que hemos adquirido con el tiempo, ya que hemos sido incapaces de detectar esta situación hasta que ISO nos ha abierto los ojos. En fin, ver para creer…

PD. Como muchos de mis compañeros ya no me consideran tan técnico como antes -ellos sabrán- aquí va una prueba que demuestra lo contrario: este paper que he enviado a USENIX, acerca del impacto de las simetrías en el cifrado. Disfrutadlo :)

La (in)seguridad del software

Hace unos meses leía en la web de Bruce Schneier un artículo en el que hablaba de la responsabilidad -o irresponsabilidad- de los generadores de software (por “generadores” me refiero a programadores, empresas de desarrollo, analistas, etc.) en la seguridad de la información. Bajo mi punto de vista, el software -en especial las aplicaciones- fallan. Fallan y mucho. Y demasiado. No únicamente desde el punto de vista de seguridad -que también-, sino incluso desde el punto de vista de la funcionalidad. Y lo peor, es que todos lo asumimos como algo habitual, como lo más normal del mundo, y como decía Schneier, incluso parcheamos nosotros mismos las aplicaciones (algo impensable con un coche, por ejemplo).

¿Por qué falla el software? Mi opinión es que en términos generales el software falla por cuatro grandes motivos; los comento, sin ningún orden particular:

La incultura de la seguridad
Muchos programadores (por programadores no me refiero únicamente a los que pican código, por supuesto) carecen de una cultura de seguridad a la hora de trabajar; simplemente no se tienen en cuenta los requisitos de seguridad de una aplicación, de un producto, ni en sus fases iniciales, ni en su implementación, ni en sus pruebas, ni en nada. El único objetivo es que funcione (hoy en día, ni siquiera que funcione rápido), que sea bonito (recuerden aquello de programa=algoritmo+marketing) y, en ocasiones, que sea tecnológicamente interesante. Poco más. ¿Seguridad? ¿Yesoqués?

El desconocimiento técnico
Incluso teniendo en cuenta la seguridad en el diseño o en la especificación de un programa, a la hora de implementarlo el desconocimiento técnico del programador hace que se cometan fallos garrafales en el código que, si no son corregidos a tiempo, acaban comprometiendo la seguridad de la información con la que tratan. No creo que valga la pena ahora hablar de errores habituales como buffer overflows o condiciones de carrera, pero alguna pregunta: ¿cuántos desarrolladores conocen el término TOCTTOU? ¿cómo se comprueban los datos que devuelve una orden del sistema? ¿qué alternativas a system() existen?

Las empresas de desarrollo
Una empresa siempre busca beneficios, y la seguridad es algo que no se ve. En ocasiones, los beneficios generados por un desarrollo seguro no se perciben desde la Dirección, por lo que en muchas empresas únicamente se busca la funcionalidad de las aplicaciones para obtener beneficios de las mismas. Dicho de otra forma, no se invierten los recursos necesarios en garantizar la calidad del software generado, únicamente se busca que la aplicación funcione y que se pueda liberar una nueva versión cuanto antes. Adicionalmente, una empresa de desarrollo no suele decir que no a nada. ¿Reprogramar la página web para poner una zona privada que enlaza con una base de datos externa? Para mañana. ¿Cifrado? Bah, no hace falta… Imaginad que necesitáramos un coche anfibio, con alas, reforzado, blindado y capaz de transportar 20 toneladas consumiendo menos de cinco litros. En un concesionario nos tomarían por locos, pero en una empresa de desarrollo nos dirían “Para mañana”. Ojo, un programa open source no suele tener la presión comercial detrás, y tampoco está libre de errores (le afectan por supuesto el resto de factores comentados aquí).

El error residual
Finalmente, incluso evitando todos los problemas anteriores, hay un porcentaje de errores que es inevitable; ese porcentaje es, a día de hoy -y de nuevo bajo mi punto de vista- demasiado alto en el desarrollo de software, y por supuesto debe reducirse a toda costa si queremos hablar de desarrollo seguro. Mientras no consigamos minimizar ese porcentaje de errores residuales, estaremos hablando de un problema serio, inimaginable en otros productos de uso masivo y diario.

¿Cómo evitar los problemas anteriores? No vamos a descubrir nada nuevo, obviamente, pero con algo tan sencillo como aplicar lo que ya sabemos, podríamos reducir, en un porcentaje muy significativo, el número de problemas de seguridad de las aplicaciones. En primer lugar, requerimos de formación e información; parece vergonzoso que en muchas facultades y escuelas de informática se hagan pocas referencias a la seguridad (si nuestra especialidad es Software, sustituyan el “pocas” por “ninguna”). Siendo así, ¿qué esperamos? Ni cultura de seguridad, ni conocimiento técnico, por supuesto. Y cuando hablamos de la dirección de la empresa, peor aún: la falta de cultura de la seguridad hace -no siempre, afortunadamente- que no se vean los beneficios que genera un desarrollo seguro. Si todos fuéramos conscientes de tales beneficios, otro gallo nos cantaría.

Finalmente, y hablando ya del error residual, creo que un factor decisivo para reducir el porcentaje de fallos es aplicar técnicas de ingeniería al desarrollo, algo que en la práctica se hace más bien poco (por mucho que en la carrera nos lo hayan explicado N veces). ¿Por qué? Eso sería seguramente material para muchos otros posts, más polémicos que este :)

La pirámide de Maslow de la Seguridad

Como se puede leer en la Wikipedia, la Pirámide de Maslow es una teoría psicológica propuesta por Abraham Maslow en su obra de 1943 “Una teoría sobre la motivación humana” (A Theory of Human Motivation). Maslow formula en su teoría una jerarquía de necesidades humanas y defiende que conforme se satisfacen las necesidades más básicas, los seres humanos desarrollan necesidades y deseos más elevados; en esta jerarquía, en el segundo escalón -justo por encima de las necesidades básicas para sobrevivir-, aparecía el concepto de seguridad en todos sus ámbitos: lo que necesitamos, una vez sobrevivimos, es tranquilidad.

Según Maslow, en la jerarquía propuesta, las necesidades más altas ocupan nuestra atención sólo cuando se han satisfecho las necesidades inferiores de la pirámide; las fuerzas de crecimiento dan lugar a un movimiento ascendente en la jerarquía, mientras que las fuerzas regresivas empujan las necesidades prepotentes hacia abajo en la jerarquía (algo a tener especialmente en cuenta en estos tiempos de crisis).

Con el tiempo, la pirámide de Maslow se ha extrapolado a ámbitos mucho más amplios que la psicología humana. En concreto, en el mundo de la seguridad, hay algunos artículos que tratan de asimilar la pirámide a niveles de seguridad o de confortabilidad conseguidos en la organización (focalizados muchos casos en la seguridad informática), únicamente bajo la perspectiva del grado de seguridad implantado. En este post hablaremos de la pirámide de Maslow de la SEGURIDAD global en las organizaciones, pero desde un punto de vista diferente: nos centraremos, como hizo Maslow, en las necesidades o deseos en cada una de las fases jerárquicas de la pirámide.

Asimilando esta pirámide a la seguridad, podemos definir un primer escalafón -la base de todo- que podríamos denominar AUTOPROTECCIÓN. En el mismo, nos interesa la seguridad y la protección de nuestros activos, pero no invertimos recursos en dicha protección; dicho de otra forma, nos dejamos llevar, aplicando las salvaguardas mímimas para sobrevivir: no cruzamos la calle cuando hay tráfico, no introducimos virus en nuestros ordenadores, cerramos nuestra oficina con llave…

Por encima de la autoprotección encontramos el DESCONTROL; en esta fase ya “sobrevivimos”, y nuestra necesidad o nuestro deseo es cubrir los aspectos de seguridad que van más allá de la mera supervivencia. Para conseguir este deseo, implantamos -o mejor dicho, permitimos que se implanten- unos controles mínimos en base al criterio personal de miembros de nuestra organización, sin mayor estructura ni coordinación. Así, nuestra seguridad depende por completo de las personas que tenemos en nuestra organización, de su buen hacer y de sus intenciones; en muchos casos, si esas personas dejan de trabajar con nosotros, sus actividades sencillamente se pierden.

Más allá de la anterior, encontramos la fase de CONTROL; aquí ya no dejamos nuestra seguridad en manos de un grupo de personas sin coordinación, sino que velamos para que el trabajo de estas personas sea correcto y reproducible, y para que esté correctamente identificado y coordinado. En la fase anterior necesitábamos cierto control para coordinar las actividades que, relativas a seguridad, se venían ejecutando en nuestra organización, y eso es lo que hemos introducido en esta fase de la jerarquía; ya no permitimos que las tareas de seguridad se hagan “porque sí”, o porque un técnico decide en un determinado momento que nos hace falta un sistema de CCTV, sino que todas siguen un hilo conductor coordinado relativamente y con un fin concreto: la protección del negocio.

Por encima de la fase de control, tenemos la de AUDITABILIDAD; en nuestra seguridad hemos superado el control, y nuestro próxima necesidad es por tanto garantizar, aparte de que las cosas se hacen bien y de forma organizada, que son trazables y un tercero (o nosotros mismos) puede analizarlas para comprobar su eficacia y su eficiencia. Así, estamos consiguiendo no sólo hacer las cosas bien, sino que los demás puedan comprobar que las hacemos bien (y con esto no nos referimos únicamente a la certificación de un sistema de gestión por parte de un tercero, sino que nos referimos a cumplimiento de estándares de auditoría interna, financiera, etc.).

Finalmente, como cúspide de esta pirámide de Maslow que nos hemos inventado, encontramos la GESTIÓN de la seguridad. No sólo garantizamos el control y la trazabilidad de nuestra seguridad, sino que además la gestionamos de forma correcta y buscamos siempre la mejora continua, por ejemplo siguiendo un ciclo de Deming; si nos centráramos en seguridad de la información, esto significaría un SGSI correctamente implantado y mantenido, pero viendo más allá de esta seguridad, la etapa de Gestión significa que invertimos los recursos necesarios en gestionar de forma correcta nuestra seguridad corporativa, tanto física como lógica, legal u organizativa.

Pirámide de Maslow de la Seguridad

Como vemos en nuestra pirámide, nuestro estado en materias de seguridad podemos ubicarlo en alguno de los escalones anteriores, y en función de donde nos encontremos, planificar el ascenso de forma ordenada, por supuesto en base a los recursos de los que dispongamos y de los plazos que necesitemos cumplir.

Para acabar, una pregunta: ¿en qué escalón de la pirámide os ubicaríais?

Operación ‘Carrusel’

Esta semana se producía en España la mayor —una vez más— operación contra la pornografía infantil en Internet, denominada Operación Carrusel (podemos ver las noticias en periódicos de tirada nacional como elmundo.es y ElPaís.com), y que se ha llevado a cabo cuando aún coleteaban las últimas actividades de la Guardia Civil en la Operación ?lbum, muy similar a la anterior pero de menores dimensiones.

Obviamente, en primer lugar mostrar mi más completa repulsa ante determinadas conductas —sexuales o no— en las que se abusa de personas indefensas, en este caso de niños, con cualquier propósito; en especial para conseguir placer o beneficio propio, como presuntamente es el caso. Ójala todo el peso de la Ley (a pesar de la tibieza del Código Penal que comentaremos en otra ocasión) caiga sobre los que abusan sexualmente de menores y sobre los que encuentran placer viendo dicho abuso.

En segundo lugar corresponde felicitar a todos los que han hecho posible estas operaciones, en especial al Cuerpo Nacional de Policía y a la Guardia Civil que, una vez más, han ejecutado de forma satisfactoria las investigaciones necesarias para llegar a los domicilios de algunos pederastas; en especial, si tenemos en cuenta la precariedad de medios con los que en muchas ocasiones estos cuerpos se ven obligados a trabajar.

Finalmente, un comentario: sé que en los medios se indica que, en el caso particular de la operación ‘Carrusel’, el rastreo era en base a ficheros con nombres tan explícitos como preteen y similares, lo cual deja poco lugar a dudas acerca del contenido del archivo descargado; pero en otras ocasiones, la Policía Nacional y la Guardia Civil investigan en base al contenido real del fichero y no a su nombre, lo que puede implicar que se meta a inocentes en el saco de los pedófilos. Dicho de otra forma, si alguien descarga un fichero que se llama bambi.mpg —ejemplo típico, aunque podríamos tratar de descargar videos aparentemente de sexo entre adultos y encontrarnos un contenido pedófilo— que contiene pornografía infantil, y lo deja olvidado en su incoming (hay gente que descarga cantidades ingentes de películas y videos que a menudo casi nunca revisa), la Policía puede entrar (orden en mano) cualquier día en su casa y requisar su equipo, convirtiendo a ese alguien en un presunto, con todo lo que eso implica (abogados, juicios, vistas, comparecencias…). Es así, y lo es porque realmente esa persona está compartiendo pornografía infantil (aunque sin saberlo).

Evidentemente, un juez o un perito sabrá distinguir —eso espero— en cada caso si la persona que tiene delante simplemente tenía un fichero con un nombre inocente en su incoming, que resultó ser pornografía infantil, o si se trata de un individuo con multitud de archivos pedófilos en su disco duro, DVDs, etc. Pero en cualquier caso, pasar por dependencias policiales o judiciales en un tema como la pedofilia —en especial si eres el acusado— es un trago que no es agradable para nadie, y menos para alguien inocente.

El nuevo CSO

Hace ya meses hablamos en este mismo blog de la convergencia de la seguridad, y en ese mismo post dedicábamos un escueto párrafo a la figura del nuevo Director de Seguridad (el CSO, como les gusta decir a los americanos).

Hasta hace unos años, en la mayor parte de organizaciones había dos figuras clave para la seguridad corporativa: el CSO (Chief Security Officer) y el CISO (Chief Information Security Officer); mientras que el primero era el responsable de las 3G (Guards, Guns and Gates), es decir, de la seguridad física o tradicional, el otro lo era de la seguridad de la información —en la mayor parte de casos, ocupándose únicamente de los aspectos tecnológicos de la misma—. Habitualmente, la relación entre ambos no solía ser la óptima (los “frikis” contra los “seguratas”), ya que por supuesto hay mucho terreno en común e incluso muchos “reinos de taifas” en juego; esta dualidad desembocaba en situaciones tan absurdas e indeseables como duplicidad de inversiones, duplicidad de esfuerzos o responsabilidades en materias de seguridad no definidas, con los consiguientes riesgos que esto implica.

Conforme los conceptos y las ideas que sustentan la convergencia de la seguridad (de nuevo, consultad aquel post de este mismo blog) comienzan a afianzarse en las organizaciones, la figura de un Director de Seguridad único se hace cada vez más necesaria. Este nuevo CSO, único en la organización, debe ser la referencia corporativa en materias de seguridad y el contacto único de la organización en este tema; obviamente, en la actualidad se trata de huir del Director de Seguridad clásico, focalizado en las 3G, y todos tendemos a buscar un CSO holístico, con una alta capacidad de gestión y capaz de gestionar el riesgo corporativo desde un punto de vista global. Como siempre, son factores críticos para garantizar el éxito -y por tanto, la seguridad- que el Director de Seguridad reporte directamente a la Dirección corporativa y que la confianza en el CSO sea total desde cualquier punto de la organización.

En España, la figura y funciones del Director de Seguridad vienen recogidas en la Ley 23/1992, de 30 de julio, de Seguridad Privada, y son autorizadas por el Ministerio del Interior. Para obtener el título de Director de Seguridad reconocido por este ministerio es necesaria, entre otras, la superación del examen o curso oficial de Director de Seguridad, realizado periódicamente en universidades y centros de estudio de todo el país; en Valencia, dicho curso puede realizarse en la Universidad de Valencia o en Florida Universitaria. Dicho curso aporta conocimientos generales de gestión de la seguridad, dirección de empresas, seguridad tecnológica, seguridad operativa y legislación, entre otros. Obviamente es un curso generalista en materias de seguridad, dirigido a su gestión efectiva y a conocimientos a grandes rasgos de diferentes áreas técnicas, que debe complementarse con la experiencia en la Dirección de Seguridad que sólo aportan los años de trabajo; en cualquier caso, un servidor echa en falta un pequeño punto en el que se hable de las tendencias internacionales en materias de seguridad, es decir, en el futuro de la seguridad desde un punto de vista holístico, que sin duda es hacia donde los directores de seguridad nos venimos dirigiendo consciente o inconscientemente.

No tan anónimos

Les confieso que en un primer momento tuve ciertas reticencias y dudas de colgar lo que les cuento a continuación, por si alguien pudiera considerarlo “incitación al delito”. Por supuesto, ese no es en ningún caso el propósito de la entrada, sino el de mostrar qué es posible hacer con unos pocos datos de carácter personal hoy en día —de esos que cualquiera de nosotros proporciona alegremente a cualquiera—, por lo que tras un par de consultas previas he decidido publicarlo. Obviamente, falta decir que lo que se cuenta en esta historia es completamente ficticio, fruto de mi imaginación, y cualquier parecido con la realidad es pura coincidencia. Sirva esto como disclaimer previo, y pasemos a la entrada.

Hace cosa de un par de semanas, a las 05:51 de la mañana, sonó mi móvil, que como siempre, había dejado encendido —mala costumbre— en la mesita de noche; con el sobresalto habitual de una llamada en horas intempestivas, contesté al teléfono sin saber quién me llamaba (tenía el número pero no estaba en mi agenda) y, para mi sorpresa, parece ser que mi interlocutor se había equivocado y, sin decir nada, ni un mísero “lo siento”, decidió colgar. A mí estas faltas de educación siempre me han molestado, pero sobre todo, me resulta incomprensible que alguien te llame a esa hora, se equivoque, y no tenga el valor de pedir disculpas ni decir nada, simplemente se limite a colgar.

Si esto se hubiera producido hace unos años, cuando no había móviles y los fijos de la época no disponían de un bonito display electrónico donde aparece el número llamante, simplemente me habría fastidiado, lo habría olvidado en unos minutos, y poco más. Pero en estos días a mi interlocutor (por llamarle de alguna forma) se le olvidó un pequeño detalle: tenía su teléfono móvil, o al menos el teléfono desde el que me había llamado; así que me propuse saber quién sería esta persona.

¿Qué hacer cuando dispones únicamente de un número de teléfono móvil, sin más datos? Puedes poner un anuncio en coches estacionados en diferentes zonas de la ciudad, pegado al cristal, con un precio atractivo y ese número de teléfono. Pero eso no supone ningún reto; sí que puede ser un reto tratar de conseguir la información de esa persona; un poco de ingeniería social nunca viene mal, y por suerte o desgracia, en este país si oímos la palabra “GRATIS” damos hasta nuestra partida de nacimiento…

A partir del prefijo móvil se puede determinar con un alto nivel de probabilidad la operadora de comunicaciones a la que pertenece, con lo que una promoción de dicha operadora siempre es una buena excusa; si ha habido una migración, pues la promoción se convierte automáticamente en una oportunidad para antiguos clientes. El resumen podría ser:

— “Le llamamos de XXXX para ofrecerle, una vez cotejados sus datos, una promoción de llamadas a 0 céntimos, GRATIS, durante todo el mes de agosto, sin letra pequeña”.
— Ah, dígame.
— ¿Es usted don Luis López, de Salamanca?
— No, me parece que se ha equivocado.
— Vaya, lo siento, entonces no puede acceder a la promoción… en cualquier caso, es usted cliente de XXXX, ¿verdad?
— Sí, sí, dígame…
— ¿Dispone usted de correo electrónico?
— Claro.
— Si me lo facilita, le enviaremos un e-mail y, simplemente por responder al mismo y rellenar nuestro cuestionario, tendrá acceso exclusivo a esta promoción.
— Claro, mi correo es yyyy@hotmail.com.
— En breve recibirá el correo; una vez obtenida su respuesta, en el plazo de una semana nos pondremos en contacto con usted para confirmarle el acceso y tendrá llamadas gratis durante todo el mes de agosto.
— Ah, muchas gracias, muchas gracias…

A partir de aquí, no hay más que enviar un correo al individuo en cuestión desde una dirección que parezca creíble; aunque para el 99% del personal es creíble cualquier dirección de Hotmail, mucho más elaborado es utilizar algo del tipo “registro@XXXXX.dyndns.org”, donde XXXX es obviamente el nombre de la operadora. En ese correo, con logos oficiales y formalismos que le den credibilidad, le pedimos amablemente su nombre, código postal —por aquello de la estadística— y el número de teléfono que quiere asociar a la promoción (aunque ya lo sepamos, nunca está de más). Et voilà, tenemos enseguida cómo se llama la persona y dónde vive (a lo de pedir la dirección postal, aparte de que no nos aporta nada, la gente suele ser más reacia, pero el código postal lo facilitamos sin problemas).

Con estos datos —nombre y apellidos, e-mail, teléfono y código postal— hemos recorrido buena parte del camino; depende de lo que queramos hacer con la información, esto es más que suficiente: desde poner anuncios de compraventa en prensa gratuita de la zona —hablaremos un día de la seguridad y autenticación en estos casos—, hasta técnicas más elaboradas; he aquí unos ejemplos:

— “Promoción” para averiguar si tiene hijos entre 10 y 20 años, y si es así, cualquier tarde de octubre, cuando su hijo esté en el colegio, volvemos a contactar con él para comunicarle que su hijo está retenido en el centro comercial X —cercano al domicilio— por haber sido sorprendido en pleno hurto, y le rogamos que venga a recogerlo. Ni hace falta saber el nombre del niño.
— “Promoción” para averiguar si su coche tiene más de cinco años y ofrecerle, en un concesionario de la zona que se ha adscrito a la promoción, una ganga. Debe pasar esa misma semana por dicho concesionario.
— Invitación a un Madrid-Barça, o Sevilla-Bilbao —dependiendo del código postal—, para él y dos acompañantes en zona VIP, completamente gratis, presentando su DNI en taquilla.
— Cualquier otra cosa que, como hemos dicho, incluya la palabra “GRATIS”.

Se me ocurren muchas más, pero ya se pasan de ser simples bromas a entrar en temas personales delicados, y después de todo, sólo fue una llamada a una hora intempestiva, y un poco de mala educación. Sirva esta entrada como reflejo didáctico, y ténganla en cuenta cuando se equivoquen de número una noche a las tantas de la madrugada y por supuesto, cuando alguien tenga la bondad de ofrecerles algo gratis.

Alan Turing

El pasado día 7 fue el aniversario de la muerte de Alan Turing (1912-1954), sin duda uno de los mejores criptógrafos de la historia, y padre de la informática teórica que aún hoy se estudia en las universidades de todo el mundo (¿quién no recuerda la máquina de Turing y las pesadillas que ésta ha generado en muchos estudiantes de Informática, entre los que me incluyo?).

Sin duda, dos bombas marcaron el desarrollo de la Segunda Guerra Mundial: la bomba atómica (obvia y desgraciadamente conocida por todos) y la bombe de Turing, una máquina desarrollada en el famoso Bletchley Park británico, vital para romper los mensajes cifrados alemanes. Esta máquina, desarrollada por Alan Turing y mejorada por Gordon Welchman, permitió a los aliados descifrar el tráfico de las diferentes fuerzas y servicios alemanes (marina, tierra, aire…) sin que éstos fueran conscientes de que la seguridad de sus comunicaciones estaba rota, lo que permitió obtener información decisiva para el desenlace final de la Guerra.

Turing fue procesado por homosexual en 1952; esto, que hoy parece impensable para nosotros, truncó la brillante carrera del británico. Dos años después, moría por ingestión de cianuro: todo indica que Turing se suicidó comiendo una manzana envenenada. De esta forma, finalizaba su vida y comenzaba el mito del gran científico, aunque los homenajes y reconocimientos públicos han sido escasos y en muchas ocasiones tardíos; quizás el más conocido en el “mundillo” en el que nos movemos es el premio Turing —considerado el Nobel de la Informática—, otorgado desde 1.966 por la ACM a quienes hayan contribuido de manera trascendental al campo de las ciencias computacionales.

Sirva este humilde post para recordar al que sin duda fue uno de los mejores científicos del pasado siglo, y quizás uno de los menos conocidos fuera del ámbito de las matemáticas, la informática o la criptografía.