Hasta el próximo viernes 29 de enero a las 15h, Security Art Work inicia el segundo consultorio online sobre la LOPD y su Reglamento de Desarrollo (pueden ver las respuestas al primero en la entrada correspondiente), a cuyas cuestiones el equipo de consultoría y auditoría de S2 Grupo contestará en la entrada del próximo viernes 5 de febrero, según nuestro mejor saber y entender.

En ningún caso se publicarán datos de carácter personal (correos electrónicos, nombres de empresas, etc.), ni se contactará con los remitentes de las preguntas, salvo que éstos lo autoricen expresamente (y lo consideremos necesario). Pueden remitir las preguntas por correo electrónico a openlopd@argopolis.es, indicarlas en los comentarios o remitirlas vía mensaje privado al usuario securityartwork de Twitter.

Según parece, el Consejo de Ministros ha aprobado el Esquema Nacional de Seguridad para la administración electrónica del que tanto hemos hablado últimamente (véase I, II y III). El artículo 13 de la primera propuesta de dicho esquema, que aparece referenciado en la página del Esquema Nacional de Seguridad, dice así:

A la vista de esto, y teniendo en cuenta en particular el texto resaltado en negrita…

[Read more…]

A lo largo de mi carrera como estudiante universitario, y más tarde durante mi etapa como técnico de sistemas, me he encontrado a menudo con el tema de debate preferido por el personal técnico —y no tan técnico— de sistemas: Windows vs. Linux. Será que me estoy haciendo mayor para discutir, o que tengo otras preocupaciones, pero lo cierto es que actualmente no es una cuestión que me preocupe lo más mínimo; si quieren saber mi opinión, cada uno tiene sus ventajas y sus desventajas, y el resto es simple miopía (o ceguera, en los peores casos). De cualquier modo, hay veces que esta discusión muta y se convierte en una igual de estéril pero mucho más relacionada a mi parecer con la seguridad, que es de lo que he venido a hablar aquí: open source vs. closed source. Es decir, código abierto vs. código propietario (que me disculpen los puristas del lenguaje y de las licencias si la traducción de Open Source no es la mejor).

Y como por lo general los que más ruido arman son los defensores del open source, lo que vengo a criticar es que sus ventajas ni son tantas ni tan buenas como sus partidarios quieren hacer creer. Aun diría más: la etiqueta en cuestión no sólo no garantiza absolutamente nada en términos de seguridad y/o funcionalidad, sino que puede inducir a engaño y una falsa sensación de seguridad, sobre todo en aquellas personas más “creyentes” en la causa. Ya verán.

Nuestra historia comienza en el momento que alguien afirma que como el kernel de Linux es open source, pues es “obviamente” mejor que Windows, porque eso nos permite modificar su código y adaptarlo a nuestras necesidades, además de que nos aseguramos de que su código sea revisado y validado por miles de ojos, y por tanto esté libre de errores o vulnerabilidades. Francamente, no sé ustedes, pero yo no conozco muchas personas de las que utilizan Linux a diario que hayan echado nunca un vistazo al código fuente del S.O. con intención de hacer algo productivo, entre los que me incluyo; a todo lo que llegué fue a la soberana idiotez de compilar todo el sistema como se puede/podía hacer con Gentoo, pero ello sin mirar ni una puñetera línea de código (que por otra parte, hubiesen dejado en evidencia mis limitados conocimientos de C). En general, cualquier vistazo a los fuentes del kernel es motivado por problemas de compilación, que nunca son problema del código sino de una configuración errónea, conclusión a la que llega uno tras decidir que ya ha perdido bastante el tiempo. Resumiendo, que el código fuente del kernel de Linux está ahí, pero aparte de unos cuantos privilegiados, nadie le mete mano por su complejidad. Y a pesar de esos miles de ojos, periódicamente se publican vulnerabilidades del kernel que se supone que el hecho de que sea código abierto nos garantiza que no deberían estar ahí.

Este último aspecto es algo que me llama mucho la atención del código abierto. Dejando atrás el kernel, hay programas cuyos fuentes son públicos, y protocolos universalmente conocidos que un buen día, después de años sin mayores problemas, resulta que algún genio en estado de gracia demuestra que son vulnerables, si Marte se sitúa en el cuarto cuadrante de Sagitario y en ese momento tienes hambre. Así, sin más. ¿Cómo es que nadie se había dado cuenta hasta entonces? ¿Pero no había miles de ojos? Protocolos abiertos, conocidos, muchas veces implementados, estudiados y revisados… ¿cómo es posible que este tipo de cosas sigan pasando, año tras año? Lo más interesante de todo es: si hubiesen sido código propietario, ¿cuánto tiempo habríamos tardado en descubrir esa vulnerabilidad? ¿Más, o menos?

Hace ya cierto tiempo, fui a parar al caso de g-archiver. La utilidad de este software, que hasta hace un tiempo podían comprar/descargar desde su web aunque era totalmente desaconsejable, es/era facilitar la realización de copias de respaldo del contenido de una cuenta de Gmail. Por fortuna, Dustin Brooks descubrió que su autor, John Terry, no sólo había cometido la estupidez de hardcodear en el código el usuario y la clave de una cuenta de Gmail, sino que además enviaba a dicha cuenta de correo el usuario y contraseña de cualquier usuario que utilizase el programa. Es cierto que esto parece un argumento en toda regla a favor del código abierto, pero lo cierto es que al menos 1700 usuarios confiaron en el programa antes de que Dustin descubriese este problema, lo cual me hace pensar que la etiqueta open source no supone en realidad ningún tipo de garantía sino que además puede llevar a pensar a los defensores del código abierto que el programa está libre de malas prácticas o vulnerabilidades graves.

Es cierto que si dicho programa hubiese sido código propietario, el problema hubiese sido probablemente descubierto mucho más tarde. Claro que eso demuestra simplemente la poca sensatez del personal, y es una lección más de que no hay que confiar en cualquier programa que encuentre uno en Internet, independientemente de si el código está disponible o no. Me atrevo a afirmar que si el tal John hubiese sido un mejor desarrollador (asumiendo que el descuido fue malintencionado y no un trozo de código utilizado para testear que desafortunadamente acabó en la versión de producción), habría sido capaz de ocultar su usuario, su clave y el envío de las credenciales de los usuarios con técnicas de ofuscación, de modo que nadie se hubiese percatado de sus intenciones al revisar el código, más que con un análisis muy exhaustivo… cosa que no es demasiado habitual.

Seguramente saben lo que es el Javascript. La mayor parte de las páginas utilizan algo de javascript, y se utiliza prácticamente para todo (y cada vez más). Además, como es código que tiene que ser interpretado por el navegador del cliente, tiene que ir en claro; si quieres ocultar algo, mejor utiliza flash (o eso creo; francamente, de tecnologías web no sé más que lo justo). Eso parece apuntar a que cualquier desarrollo que hagamos puede ser “robado” por otros desarrolladores. Nada más lejos de la realidad; existen programas para comprimir y ofuscar el código, que lo hacen virtualmente ininteligible para cualquier persona, incluyendo a su autor. Por tanto, el hecho de que dispongamos del código de dichos desarrollos no supone ni una ventaja ni una desventaja; unas veces es una necesidad de tamaño (tamaño del código) y otras una necesidad de protección (propiedad del código).

Podría parecer, llegado este punto, que defiendo que el código propietario es más seguro que el código abierto. Pues tampoco. La muestra son no sólo las frecuentes vulnerabilidades del software propietario como el de Microsoft, Adobe y otros, sino la velocidad a la que dichas vulnerabilidades se descubren cuando alguien está realmente interesado en encontrarlas (véase cualquier código relacionado con DRM). Por tanto, la verdad es que por lo general da exactamente lo mismo; no se fíen ni de uno, ni de otro. Con lo cual llegamos a lo que les comentaba al principio: que la conversación es tan estéril como el del huevo y la gallina, y tampoco sirve para dar conversación a la vecina del sexto en el ascensor. Es más, seguro que te mira raro y piensa que eres un friki; mejor utiliza la previsión del tiempo.

Acabo. Si recuerdan, el principio denominado “Seguridad por oscuridad” (Security thru obscurity) consiste en ocultar los detalles de diseño e implementación —entre otros— de un programa o dispositivo, consiguiendo que el producto actúe como una caja negra y por tanto sus potenciales puntos débiles no puedan ser descubiertos. En principio, eso se considera una mala política, porque además de que la exposición pública incrementa la posibilidad de que sus vulnerabilidades sean descubiertas (algo que como hemos visto no exactamente cierto), siempre hay alguien que acaba descubriendo sus vulnerabilidades, explotándolas, y entonces es cuando decimos que una vulnerabilidad esta siendo explotada “in the wild”. Lo cierto es que eso pasa con código abierto y con código propietario, a pesar de lo que puedan pensar; las vulnerabilidades están ahí hasta que alguien las descubre públicamente, y mientras tanto, quién sabe.

El problema no es, en realidad, código abierto frente a código cerrado. El problema son empresas responsables frente a empresas irresponsables. No me hagan dar nombres, que me entra la risa.

Nada más. Tengan cuidado ahí fuera y pasen un buen fin de semana.

Aprovechando que es viernes, se acerca la Navidad y para bien o para mal vamos desconectando poco a poco del trabajo, vamos con un par de ejemplos fáciles de cómo no hacer las cosas. Por partes.

Si viven ustedes en Valencia, verán que la Empresa Municipal de Transportes (EMT) ha sustituido las tarjetas de Bono Bús, habitualmente de cartón, por tarjetas de plástico contact less (ignoro los detalles de la tecnología), no sólo mucho más aparentes estéticamente (eso es lo de menos, en realidad), sino que entre otras cosas permiten ser recargadas con más de 10 viajes, y si se registra el soporte, aunque el soporte se pierda los viajes son recuperables (asumo que la tarjeta original deja de funcionar, porque en otro caso la picaresca daría lugar a situaciones del tipo “¿y si perdemos mi tarjeta?”). Además, para facilitar e incentivar la “migración” a los nuevos soportes, si registras el número de la tarjeta llamando al número de atención al cliente de las oficinas centrales de la EMT, el coste de la tarjeta (2 euros), se reembolsa en forma de viajes directamente en la tarjeta. Hasta aquí, bien.

El problema es que el registro de la tarjeta requiere que des el identificador del soporte, tu nombre y apellidos, tu situación laboral, los usos de la tarjeta, frecuencia de uso, líneas utilizadas, y varios datos más que no vienen para nada a cuento y que no incluyo por no incurrir en imprecisiones. Para muchas personas que no se dedican a esto de la LOPD, la percepción que les quedará tras la “conversación” es que se han solicitado/proporcionado un volumen de datos personales sin que nadie les diga para qué necesita la EMT todo eso, o incluso si es necesario que los proporcionen. Es decir, sin informar de su tratamiento, finalidad, cesiones previstas y otras tantas obligatoriedades que la persona que me atendió (y sin ninguna duda su responsable) ignoraba… aunque ya sabemos que el desconocimiento no exime del cumplimiento de la ley. En cualquier caso, dejando de lado la gravedad de la cuestión, lo que me parece preocupante es que una empresa municipal lleve a cabo este tipo de iniciativas sin las debidas garantías. Más que preocupante, indignante.

De una clara irregularidad pasemos ahora a una mala práctica en Seguridad de la Información. Se habrán fijado sin duda que es habitual que las sucursales bancarias tengan cristales en lugar de paredes, lo que incrementa la sensación de apertura y vayan a saber ustedes que otros aspectos de marketing y percepción. Esto es particularmente evidente cuando la sucursal hace esquina, y puede verse desde fuera toda la disposición de despachos y personal. El problema es que en ocasiones se ve mucho más que eso. Si la posición de mesas y despachos no ha sido cuidadosamente planificada por alguien con un poco de idea (y sentido común), puedes acabar con pantallas ubicadas de cara al cristal, papeles que pueden verse fácilmente desde la calle, etc. Si a eso le añadimos que cualquiera puede agenciarse hoy en día una cámara de video con zoom, tenemos todos los ingredientes para un robo de información corporativa, de datos de carácter personal, contraseñas, etc. Hagan volar su imaginación, seguro que la realidad supera a la ficción.

Nada más. Vayan pensando en sus propósitos para el nuevo año, que pueden ser los del año pasado si no se les ocurre nada. Nosotros nos vamos hasta el lunes. Pasen un buen fin de semana y abríguense, parece que va a hacer un poco de fresco.

Cuando uno lleva mucho tiempo relacionado con entornos de monitorización y aspectos relacionados, tanto a nivel técnico como de gestión, acaba viendo sistemas susceptibles de ser monitorizados por todas partes (y las implicaciones derivadas). Verán porqué les digo esto.

En mi empresa, S2 Grupo, tenemos una máquina de vending, ya saben, de esas que sirven botes de refrescos, rosquilletas y chocolatinas varias. Ya conocen la estructura: la máquina tiene varios estantes, uno encima del otro, y cada estante está formado por varias filas con diferentes productos; similar a la de la imagen. El problema es que algunos compañeros hemos observado que existe un significativo margen de mejora que podría ser aprovechado mediante un sistema de monitorización y control del consumo de los productos. En realidad, no es que exista margen, sino que parece que no existe ningún tipo de gestión racional del consumo de los clientes. Veamos cuáles son los problemas:

• En primer lugar, aunque en la empresa tenemos dispensadores de agua mineral, la máquina en cuestión dispone de dos filas con botellas de agua mineral. A pesar de las indicaciones que se han dado de que nunca, nadie, por ninguna razón comprará una botella, ahí siguen. Es decir, hay productos que aunque nadie consuma, se mantienen. Como suele decirse, me lo expliquen.
• Soy un adicto al Kinder Bueno, lo reconozco. Un Kit-Kat sirve de reemplazo decente, pero no es lo mismo. En cualquier caso, esos significa que esos dos productos se agotan con mucha más rapidez que la mayoría del resto de productos de la máquina. A pesar de ello, cuando la fila de mi producto favorito^TM se agota, en lugar de volver a poner Kinder Bueno, es reemplazado por otro (Kit-Kat en el mejor de los casos, pero no siempre). En este caso, lo que tenemos son dos problemas: no hay un seguimiento de los productos que más se consumen, y a causa de ello éstos se sustituyen por otros de consumo inferior, interrumpiendo tanto el componente de fidelización (i.e. la costumbre voy a la máquina a por algo), como desaprovechando el beneficio potencial de la instalación.
• En tercer lugar, hay productos que durante los meses que la máquina ha estado instalada apenas han sido consumidos, y cuya fila se agota mucho más lentamente que la de los productos más habituales. Por poner un ejemplo concreto, poca gente bebe Fanta Naranja/Limón. No me pregunten porqué; la gente tiene gustos particulares. En el otro lado, la Coca-Cola se agota a unas velocidades de vértigo. Sin embargo, ahí siguen esas filas desaprovechadas (a pesar de los esfuerzos del personal de Administración por intentar hacer entender al reponedor de la máquina lo que es lógico). Sí, quizá a alguien le apetezca beberse una Fanta en el solsticio de verano, pero qué c***, esto no es un asunto de igualdad de oportunidades; es un simple refresco. Seguro que la Coca Cola le va bien, y si no que beba agua o que beba Fanta más a menudo (discúlpenme los amantes ocasionales de los refrescos de naranja y limón).

En definitiva, lo que tenemos es una máquina de vending con productos que no se compran, otros que apenas se compran, otros que se venden con facilidad pero no son repuestos, y otros cuyo número de filas es muy inferior al deseado por el consumo que tienen. No me negarán que si fuesen ustedes el gerente de la empresa distribuidora, no es una perspectiva desalentadora.

Hay varias soluciones, de diferente nivel de complejidad técnica, que podríamos aplicar a este caso (y que sin duda algunos proveedores ya están aplicando):

• En primer lugar, realizar un control estricto del consumo de la máquina. Retirar los productos que no se consumen o apenas se consumen, incrementar el espacio dedicado a productos que se agotan rápidamente, y escuchar a los clientes (podría plantearse preguntar a la organización donde la máquina se instala un conjunto de productos inicial, a completar por la empresa de vending). La cuestión aquí es que nadie compra una botella de agua mineral por 50 céntimos si tiene botellas de 30 litros gratis distribuidas por la empresa. Nadie en absoluto. Véase el problema de las discográficas para más detalles de porqué la gente no quiere pagar por algo que tiene gratis (dejemos de lado los detalles, ya que está claro que la ADSL no es gratuita).
• Por supuesto, llegar a un conjunto de productos semi-óptimo en términos de consumo lleva un tiempo, aunque el proceso podría acelerarse si se consultase a los clientes, y durante los dos primeros meses las visitas del reponedor fuesen semanales, en lugar de quincenales o cada tres semanas. Eso facilitaría que una vez alcanzado un nivel de estabilidad, las visitas pudieran pasar a ser mensuales.
• Monitorización del consumo de la máquina. Hay varias opciones para realizar esto. Por supuesto, un sistema autónomo que de manera periódica remitiese vía módem GSM la ocupación de la máquina a central sería lo mejor; eso optimizaría los viajes de los reponedores. No obstante, eso implicaría al fabricante de las máquinas (aunque no estoy familiarizado con el estado del arte de este tipo de máquinas, seguro que ya existen modelos que disponen de esta funcionalidad), y quizá aumentaría el tiempo de amortización de la instalación al incrementar el coste (aunque reduciría los desplazamientos de los reponedores, por lo que sería necesario estudiarlo en profundidad). La segunda opción podría ser una pistola RFID donde el reponedor apunta los consumos realizados desde la última visita, y los descarga al llegar a central. Por último, tenemos el caso más simple: lápiz y papel, y los datos pasados manualmente al llegar a central; un fastidio, pero tecnológicamente barato de adquirir y mantener.
• ¿Qué hacemos con los datos obtenidos? Muy sencillo. Para cada una de las máquinas que gestionamos, detección de productos cuyo porcentaje de consumo es inferior o superior a unos umbrales predeterminados, líneas de tendencia, y rentabilidad por instalación. A partir de ahí, cada reponedor podría disponer de una planificación semanal detallada y semi-automátizada de dónde y cuándo ir, así como qué llevar. Llevando el ejemplo un poco más allá, podría ser interesante, en función de la dispersión y volumen de instalaciones, incluir temas de investigación operativa en la que optimizásemos las rutas de los reponedores.

Esto es, sin entrar en demasiados detalles, alguna de las mejoras que podrían plantearse en este caso con un poco de monitorización y control de las instalaciones; les diría que es posible que la empresa que nos suministra los productos esté haciéndolo, pero francamente, todo apunta a que no es así, porque de serlo, yo tendría mi Kinder Bueno, que es lo que importa. A nivel técnico, no se requiere mucho si nos decantamos inicialmente por la opción más simple. Organizativamente, sí, es algo más complejo; implica un nivel nada despreciable de gestión, coordinación, análisis y seguimiento, tanto con reponedores, clientes, proveedores y demás, incluyendo el departamento comercial; nadie dijo que fuese a ser cantar y coser. Tampoco hay que obviar el hecho de que puedan existir contratos con determinados proveedores que nos obliguen a dedicar un porcentaje fijo de espacio en la máquina a sus productos; la viabilidad y rentabilidad de dicha ocupación debería ser también analizada. Por último, otra variable importante es el margen de beneficio por producto, que debería ser estudiado y puesto en contraste con su volumen de ventas; un margen pequeño puede ser rentable en productos consumidos masivamente, pero da igual si el margen es muy elevado, si no vendemos ni una Fanta (bueno, sí, una: en el solsticio de verano).

Quizá les parezca que una máquina llena únicamente de Kit-Kat, Coca-Cola y Kinder Bueno (por simplificar las cosas) es… “un poco triste”. Que en la variedad está el gusto, y cosas así. Pero en realidad no. Lo que es triste es que un cliente quiera un Kinder Bueno a media tarde y encuentre que en su lugar, hay unas galletas con sabor vayaustedasaberqué que desde luego él no va a comerse. Eso es realmente lo triste, porque él se queda sin su chocolate y ellos sin su dinero.

Acabo. Les aseguro que el margen de rentabilidad de “nuestra” máquina de vending existe, y presiento que no es despreciable. Lo que significa, en pocas palabras, que alguien está perdiendo dinero (y no soy yo, que si por no he sido bastante obvio, estoy deseoso de gastármelo en Kinder Bueno). Me atrevería a decir que en todas las empresas existen aspectos como este, susceptibles de mejora, pero que por inmovilidad, falta de iniciativa/innovación/análisis, o aspectos culturales, no se ponen en marcha. Ahí es donde entra BAM, de lo que esta entrada podría considerarse un ejemplo aplicado —y algo tonto, no lo niego.

(Por supuesto, admito la posibilidad de que nuestro proveedor haya valorado lo que les comentaba previamente, y tras analizarlo, lo haya descartado… pero de nuevo, no lo creo).

Para hoy, tenemos un par de breves cuestiones relacionadas tangencialmente con la Seguridad de la Información.

En primer lugar, me gustaría presentarles el blog Spring Art Work, un blog mantenido principalmente por nuestro compañero Néstor Tarín, en el que tratará de cuestiones propias de desarrollo en el uso de frameworks —principalmente Spring, tal y como indica su nombre— utilizados para el desarrollo de aplicaciones (java y .Net) de manera cómoda, sencilla y correcta. Se trata de un blog técnico que incluirá artículos de distintos niveles de dificultad, y puede ser útil para comprender conceptualmente el uso de los frameworks presentados desde un perfil no técnico. Inicialmente su periodicidad será semanal, pero probablemente se incrementará a medida que el blog vaya cogiendo velocidad.

En segundo lugar, si llevan algún tiempo siguiendo el blog, sabrán que de un tiempo a esta parte hemos incrementado la frecuencia de publicación hasta hacerla diaria, exceptuando los fines de semana y algún día suelto que la inventiva está por los suelos. No obstante, teniendo en cuenta la relativa densidad de algunas entradas, tenemos cierta curiosidad por saber cuál sería la frecuencia de publicación ideal para nuestros lectores; si estamos llegando, nos quedamos cortos o nos pasamos. De ahí que hayamos creado la encuesta que les muestro debajo.

Mañana continuaremos con la programación habitual.

Con poco que hayan seguido este blog, sabrán que no hacemos un uso comercial de éste, primero porque no nos gusta, segundo porque existe contenido mucho más interesante, tercero porque no es ese el propósito de un blog, y por último porque eso supondría ahogarlo irremediablemente. Dicho esto, no obstante, en este caso nos disculparán si hacemos una excepción, que en mi opinión está justificada.

S2 Grupo ha iniciado un ciclo de conferencias y cursos especializados en la línea del trabajo que desarrolla, y en este sentido, para el próximo mes de diciembre (concretamente, 14, 15, y 16 de diciembre) hemos organizado, en colaboración con New Horizons (actualmente Tecnofor), el segundo curso de formación especializada en ITIL e ISO 20000 con certificación APM GROUP opcional al finalizar la acción formativa. El curso consta de un módulo de Introducción al código de buenas prácticas ITIL, una revisión a la norma internacional ISO/IEC 20000 y un caso práctico de Gestión de Incidencias basado en lo sucedido en el Apollo XIII.

A diferencia de la mayor parte de los cursos, para los que es necesario desplazarse a Barcelona o Madrid, éste se impartirá en las nuevas instalaciones de S2 Grupo en Valencia (C/ Ramiro de Maeztu), lo que supone un ahorro considerable en desplazamiento y alojamiento para aquellas personas o empresas cercanas a Valencia y que estén interesadas en asistir a un curso de este tipo. Los cursos se imparten en grupos reducidos para poder sacar el máximo provecho.

Pueden obtener más información de los anexos que se incluyen a continuación, mandando un correo a formacion [en] s2grupo.es, o llamando al 96 3110300. Mañana retomaremos la programación habitual.

Más información: [Información del curso] [ITILv2] [ISO 20000] [Caso práctico: Apollo 13]

En enero realizaremos un curso de similares características basado en ISO 27001, del que les daremos detalles más adelante. No obstante, si podrían estar interesados y desean información sobre éste, ya conocen los datos de contacto.

No sé si recuerdan la entrada titulada “El cuento de la lechera en la nube 2.0 (o porqué Google no contesta con rotundidad)” que escribimos en este blog hace ya unos cuantos meses, a raíz de la polémica desatada por Javier Mestre con su crítica al gigante estadounidense y el riesgo de utilizar Google Apps Premium Edition en entornos corporativos.

Sea como fuere, en los comentarios de aquella entrada se creó un (pequeño) debate entre “g” y Edgard que me parece muy interesante de cara a entender qué entendemos por seguridad. Resumiendo, la cuestión se sitúa en torno a la confianza que la declaración/compromiso/”contrato” de confidencialidad que Google genera en el usuario de sus servicios. Edgard lo expresó de una manera cristalina: “[…] Me temo que si Google cumpliera con toda la legislación habida y por haber seguiría siendo una opción un tanto arriesgada desde el punto de vista de la confidencialidad de los datos.“. Efectivamente, no hay que olvidar que el buscador está bajo el paragüas del acuerdo de Puerto Seguro (dejemos de lado las numerosas pegas que tiene este acuerdo, por decirlo de una manera suave), y que sin duda implanta innumerables controles físicos y lógicos para preservar la confidencialidad de los datos que gestiona, independientemente de su tipología. Dicho de otra forma, y dejando de lado los datos de carácter personal, me atrevo a afirmar que hay pocas pegas que ponerle a Google en la gestión de los datos de sus clientes y usuarios, y que legalmente está totalmente regularizado, quizá mucho más que otras tantas multinacionales de telecomunicaciones u organismos públicos. Y aún así, a pesar de esto, Google sigue sin transmitir una sensación de seguridad, cuyos detractores están en muchos casos relacionados con la seguridad de la información.

Dejemos a Google; en este caso es sólo un ejemplo. Lo que me interesa de lo expuesto hasta ahora es: tal y como expuso “g” en aquel caso, si Google dispone de todas las garantías legales, ¿no debería traducirse eso en que tiene todas las garantías? Parece ser que no; la sensación de seguridad va mucho más allá en este caso del cumplimiento legal en forma de una declaración o compromiso de confidencialidad. Pero, ¿está este hecho condicionado por la situación global y en cierto sentido hegemónica del gigante americano? Probablemente sí; de hecho, muchas empresas locales gestionan una gran cantidad de datos de pequeñas empresas y autónomos sin que exista un contrato de confidencialidad por medio, y aunque lo haya, los controles lógicos y físicos son probablemente menos exhaustivos que los de Google.

¿Estoy diciendo que deberíamos confiar en Google para que gestione el correo corporativo? No; sigo pensando que mantener información confidencial en los sistemas de la organización aporta una seguridad (en el vertiente de la confidencialidad) que ningún sistema puede todavía igualar, y Google no es una excepción. El hilo de la argumentación es el opuesto: si no confiamos en Google a pesar de sus indudables esfuerzos e inversiones en seguridad, ¿deberíamos confiar en un proveedor, un cliente, o un empleado que va a tratar nuestros datos por el mero hecho de la firma de un compromiso o contrato de confidencialidad? La respuesta es obvia: no. Dejando de lado aquellos casos en los que ni siquiera existe tal firma, aunque legalmente un documento de este tipo supone una garantía, en muchos casos detectar y probar una filtración o robo de información es más bien complejo y costoso, por no decir casi imposible, excepto en casos muy obvios, en los que el volumen de información es significativo y es utilizado de manera muy obvia fuera de la organización.

Por tanto, concluyendo, creo que queda claro que la seguridad de un proveedor, cliente o empleado no puede limitarse a un mero documento firmado (tampoco hemos descubierto nada nuevo aquí). El caso es: dejando aparte la cuestión o garantía legal, ¿de qué sirve un compromiso de confidencialidad? ¿Es algo más que un apretón de manos, un “puedes confiar en mi”, una declaración de intenciones, una formalidad que viene a representar una sensación: la confianza?

Se lo dejo como reflexión para estos dos días. Pasen como siempre un buen fin de semana.

Vaya por delante que cualquier parecido de lo que les voy a contar con la realidad es pura coincidencia. Vamos, que se trata de una situación hipotética, que no se trata de un caso “tengo un amigo que”. Vamos con ello.

Imagine que usted descubre un día, por casualidad o mientras investigaba, un gran problema de seguridad en el software o hardware de uno de los grandes. Cuando digo grande, me refiero grande en ambos sentidos; uno de esos que hacen desplomarse las cotizaciones en bolsa del afectado: Microsoft, Sony, Dell, Google, Hewlett Packard, Oracle, Intel, etc. Vamos, un problema de los gordos para una compañía de las gordas.

Podemos asumir que el primer paso que muchos darían, excepto aquellos interesados por aprovechar el problema de seguridad in the wild —a los que vamos a dejar de lado en este hilo de suposiciones— sería ponerse en contacto con la compañía para comunicarle el hallazgo. Sin embargo, aunque es razonable esperar una respuesta positiva por parte de ésta, no podemos descartar que descubrir algo que puede suponerle una terrible migraña al fabricante ponga en acción a su equipo de abogados, y éste te llame a ti, amenazándote con una demanda y una posible indemnización millonaria por daños y perjuicios a la marca si el tema se hace público. Que tengan o no razón nos da lo mismo; meterse en algo así es un problema ganes o pierdas.

Así que, previniendo eso, la comunicación con el proveedor se hace de manera segura, y tomando todas las precauciones razonables para que éste no pueda averiguar la procedencia del mensaje, le hacemos llegar a la empresa en cuestión el problema. Pasan los días, pero nada pasa. No hay anuncios oficiales, no hay ningún tipo de parche de seguridad; como si nada hubiese pasado, un mes, dos meses, tres meses, y nada, absolutamente nada. Vacío.

Llegado este punto, usted ha hecho todo lo que es razonable, y dado que está totalmente en contra de que la seguridad pueda alcanzarse a través de la oscuridad (Security thru obscurity), se plantea hacer público su hallazgo. No hay nada peor que un problema de seguridad que el fabricante no ve la necesidad de parchear, porque no es público. Al final siempre habrá gente que lo conozca, dispuesta a aprovecharlo. Siempre.

Claro que aquí volvemos al problema del inicio: exponerse a una demanda millonaria, aparte de vayaustedasaber qué técnicas de desprestigio personal que pueden afectar seriamente a su vida profesional (entre otras cosas). La primera opción sería recurrir al anonimato; colgar la vulnerabilidad en cualquier foro, dando los detalles de la vulnerabilidad y la respuesta de la empresa, y poner todas las medidas posibles para ser virtualmente ilocalizable. Claro que eso tiene dos pegas: la primera, que renuncia usted a cualquier tipo de prestigio o reconocimiento por el descubrimiento, y la segunda, que siempre quedan huellas y por tanto la posibilidad de que den con usted.

Es obvio que se trata de una hipótesis, y que la empresa no tiene porqué comportarse de esa manera, pero eso es algo a lo que no vale la pena arriesgarse. A la vista de todo lo anterior, ¿renunciaría usted a la publicación de la vulnerabilidad, dejando que unas semanas, meses o años más tarde fuese otro quien se llevase los laureles… y los problemas? ¿Dejaría un problema de esta magnitud tapado?

¿Qué haría usted?

(La fotografía es del mayor agujero del mundo, una mina de diamantes en Mirna, en Siberia [Google maps])

—

(Hemos visto que la práctica totalidad de las cuentas de Hotmail suscritas al blog por e-mail no han sido verificadas. Si es su caso, por favor revise la carpeta de correo basura y verifique la suscripción. Pasen un buen fin de semana.)

Me despertaba esta mañana con la noticia de que el Partido Popular ha propuesto en el Congreso de los Diputados que a) los menores de 18 años necesiten consentimiento (actualización: al parecer, ahora ya sólo piden conocimiento) para acceder a las redes sociales, y b) los menores de 14 años no puedan siquiera acceder a éstas ([elmundo.es][ElPais.com]). Francamente, la primera de ellas me parece una barbaridad en toda regla, y aunque la segunda es más lógica por aquello de la edad, les diría que también estoy en desacuerdo. Veamos.

Lo primero que se me ocurre es que, en un país en el que existe actualmente, y a la vista de los últimos delitos, un debate sobre reducir o no la edad penal de los menores de la actual 14 a 12 años, parece una contradicción que una persona de menos de 18 años, que a partir de 16 puede conducir una motocicleta, tenga que solicitar autorización paterna para acceder a las redes sociales. Entonces, ¿debemos o no considerar a una persona madura a los 16 años? ¿Sí o no? ¿Sí para entrar en la cárcel, pero no para entrar en las redes sociales? Si asumimos que una persona de 15 años debe ser responsable penalmente de sus actos… bueno, pues ya saben cómo sigue el argumento.

Ya lo sé. La finalidad de rebajar la edad penal y la de incrementar la edad “tecnológica” (porque esa es al fin y al cabo la idea) es diferente. En este caso, se trata de proteger al menor de todo el abanico de “sujetos” e indeseables que pululan por las redes sociales. El problema es que pensar que Internet está limitado a las grandes redes sociales Tuenti, Facebook y MySpace es por completo ingenuo y una muestra más del desconocimiento de Internet del estamento político (en esto es fácil generalizar). Por suerte para aquellos que no somos especialmente aficionados a las redes sociales, Internet es mucho más que las tres Marías de arriba o todo lo que les he enumerado: hay infinidad de chats, pequeñas redes sociales, foros de aficiones (algo a lo que, vaya por Dios, los menores suelen ser muy propensos), blogs, sistemas de mensajería instantánea como MSN, ICQ, o Gtalk, y eso para empezar. Entonces, ¿es factible que los menores de 18 años necesiten consentimiento para acceder a Internet? Estaremos de acuerdo en que es una barbaridad, ¿cierto? En su lugar, ¿no sería mucho más lógico enseñar a los menores, independientemente de su edad, a aplicar las medidas de protección que aplican en su vida diaria? Ya saben, no fiarse del primero que pasa, no dar datos personales, no aceptar “caramelos”, no exponer tu vida íntima, etc.

Claro que en Internet hay contenido pornografico, violento, racista y totalmente perjudicial para los menores, todo ello accesible sin ningún tipo de restricción; sólo hay que buscarlo un poco, y cuesta poco nada encontrarlo. Sin duda, está llena de indeseables; real como la vida misma. ¿Vamos a prohibirle a un menor de 18 años que vaya al cine, salga de fiesta o simplemente quede con los amigos en una plaza cualquiera (por la que muy probablemente de vez en cuando pasa algún camello, algún delincuente, algún skinhead, o algún sujeto de pocos escrúpulos)? Creo que no, ¿verdad? (Si intentan prohibir ese tipo de cosas, suerte con sus hijos y las autoridades judiciales). Educación.

Verán, durante toda mi vida he ido de vacaciones a un pequeño pueblo de la provincia de Valencia, llamado Cortes de Pallás [Google maps]. Durante los últimos años, un extraño fenómeno ha sucedido: cuando llega la hora de la siesta, un puñado de menores se reunen en las escaleras de la vieja escuela, con el portátil en las rodillas, y allí se pasan sus buenas dos horas hasta que (imagino) la batería del portátil no da más de sí. ¿La razón? Es el único lugar del pueblo que dispone de conexión a Internet vía Wifi, es decir: Tuenti, Facebook, MSN, etc. No entraré a valorar la idiotez de esta costumbre, propia de la adolescencia y la pubertad, teniendo una fenomenal piscina que a las cuatro de la tarde es todo un lujo, pero si quiero comentar sobre la prolongación de la vida social en que se ha convertido Internet para los menores; les permite estar en contacto con sus amigos casi de manera permanente, compartir fotos, experiencias, comentarios, y cotilleos, y eso es algo que, aunque uno haya tenido una adolescencia moderadamente autista, a esa edad es imprescindible. Es más, voy a llevar ese argumento un poco más lejos: quizá no hoy, pero dentro de unos años no estar presente en Internet de manera activa puede llegar a ser una carencia social importante.

Con lo que vamos al siguiente punto. Hemos hablado de la necesidad de educar, no prohibir, y de lo vital que es Internet para las relaciones sociales (de todo tipo). Pero lo cierto es que las redes sociales son el punto de entrada de muchos menores a Internet, la excusa si quieren, a partir del cual desarrollar toda una identidad digital, y familiarizarse con la tecnología. Si no tener Internet en casa te pone en desventaja con otras personas (hoy quizá no, mañana sin duda), limitar mediante prohibición el primer contacto de los menores con Internet sólo conseguirá ponerlos en desventaja con los menores de otras partes del mundo, e incrementar la edad de la primera toma de contacto con Internet y los ordenadores. Es decir, con el futuro.

Aunque hay sin duda innumerables argumentos en contra de la propuesta, acabo con el más típico. No cabe duda de que el Estado debe estar ahí para velar por la seguridad de sus ciudadanos, independientemente de su edad, pero no nos pasemos. En primera instancia, quien debe velar por la seguridad de un niño son sus progenitores; quizá sería mejor dotarles también de una necesaria formación, y animarles a estar en contacto con sus hijos en las mismas redes sociales. Decisiones como dar a un menor un portátil, o poner un PC en su habitación deben ser previamente reflexionadas y no tomadas alegremente, con su necesaria dosis de diálogo y conversación. Una cosa es prohibir a un chaval de 16 años salir de casa a cualquier hora y a cualquier sitio, y otra muy diferente verlo salir el viernes y no preocuparse por él hasta el lunes. Sí, ya sé que es lo de siempre, pero es lo que hay.

Acabo. Dicen que tememos aquello que desconocemos, y no me cabe duda de que esa es la raíz de la prohibición propuesta. Por suerte, les guste o no, Internet ha venido a quedarse, y sus ventajas y oportunidades superan con mucho sus problemas.