(A raíz de una desconcertante experiencia de la que he sido espectador esta mañana cuando esperaba en la cola del cajero para ingresar dinero, me ha parecido oportuno recuperar esta entrada, que fue uno de los primeros posts de este blog allá por mayo del 2007, que sin duda muchos de ustedes no habrán leído y los demás seguramente la habrán olvidado)

El pasado fin de semana estuve viendo por tercera o cuarta vez Casa de Juegos, de David Mamet; confieso que la recordaba mejor. Supongo que en cierto sentido, por eso el poeta cubano decía aquello de No vuelvas a los lugares donde fuiste feliz; nuestra memoria no siempre es fiel a la realidad. La película en cuestión es de hace ya veinte años, en la que Mike (Joe Mantegna) es un timador dispuesto a desvelarle los trucos y entresijos de su “oficio” a una psicóloga (Lindsay Crouse) demasiado curiosa.

Hoy un cliente me preguntaba sobre posibles medidas a implantar para evitar la fuga de información corporativa, y me apuntaba a la utilización de DRM (Digital Rights Management) y DLP (Data Loss Prevention) para controlar el flujo de información, sobre lo que además tal y como me indicaba no hemos escrito nada en el blog. Me comprometo ya mismo a escribir sobre ello en las próximas semanas (si no pueden esperar hasta entonces, sobre DLP la gente de Websense tiene un PDF bastante detallado en este enlace), pero en cualquier caso, es pertinente comentar unos puntos básicos al respecto de estas tecnologías:

• Este tipo de soluciones suelen tener un coste de adquisición e implantación no despreciable, si se pretende obtener una buena efectividad.
• Además del coste económico implícito, el mantenimiento y gestión de estos sistemas y la información que generan requiere su tiempo, que puede ser significativo y que al final se traslada en un mayor coste.
• Estos sistemas no son infalibles 100%; aunque limitan mucho la gestión no autorizada de información, no son la panacea ni hay que olvidar el resto de medidas (que incluyo en la segunda parte de esta entrada).
• Finalmente, estos sistemas introducen restricciones al flujo de información que pueden generar un torrente de quejas entre el personal, que el Departamento de Informática debe estar listo para asumir y gestionar; dicho de otra forma, es bueno que la organización sea consciente de qué está implantando y que Dirección ofrezca todo su respaldo… para poder utilizarla de escudo en caso de apedreamiento público.

(Para hoy martes, una entrada de uno de nuestros colaboradores habituales, Francisco Benet, sobre la necesidad de dotar de un cuerpo documental a la operación de nuestros sistemas y hacerlo con el menor sufrimiento posible)

La creación de procedimientos es una de esas tareas que muchas veces, por no decir siempre, se pasa por alto dentro de las tareas propias de la gestión de sistemas. Naturalmente no es algo que a los técnicos les agrade mucho, precisamente porque lo que a un técnico le gusta es ‘jugar’ con los cacharros que tiene a su disposición; eso de escribir no es que sea sólo para novelistas, sino que cuando llega la fatídica hora de pasar al papel lo aprendido, o se ha olvidado, o ha pasado a ser la tarea menos prioritaria de las pendientes (a veces porque hay justificadamente otras tareas más urgentes, y a veces porque “se buscan” esas otras tareas). En definitiva, es una de esas cosas que presentan más batalla para el personal que esta operando y explotando los sistemas; según mi experiencia personal, si tuviera que decir cuál es la tarea más problemática que me ha tocado lidiar en el trato con las super-estrellas-técnicos-de-la-muerte, sin lugar a dudas diria que es la procedimentación de una plataforma, no tanto por el contenido sino por la calidad y la dedicación a la redacción, porque un procedimiento mal hecho es casi lo mismo que nada, por la rapidez en que cae en desuso y lo poco que se utiliza.

Hace unos días leía una interesante entrada de Alonso Hurtado sobre la disparidad de jurisdicciones en relación con las redes sociales, basada a su vez en una entrevista a Natalia Martos, directora del Área Jurídica y Privacidad de Tuenti.

En dicha entrada, Alonso hace una reflexión sobre la diferencia de obligaciones y requerimientos en materia de protección de datos que existe entre Facebook y Tuenti, al someterse a jurisdicciones diferentes, la estadounidense y la europea, siendo la primera mucho más laxa que la primera (y más si tenemos en cuenta que la LOPD es una de las leyes más restrictivas de la UE), y parece abogar por una relajación de las restricciones en materia de protección de datos para evitar la ventaja competitiva de empresas como Facebook frente a Tuenti. Al respecto, es cierto que Facebook y otras empresas extranjeras tienen una ventaja significativa frente al “producto nacional”, pero no creo que se limite a las organizaciones estadounidenses, sino a la práctica mayoría de empresas que operan en Internet con datos de carácter personal; la directiva 95/46/CE da el suficiente margen de libertad para que su aplicación entre unos estados y otros sea significativa, por lo que en la práctica, estamos en desventaja no sólo con los EEUU sino con prácticamente todo el globo terráqueo, dado que la aplicación española de la directiva tiene fama de ser la más (o una de las más) restrictiva de Europa.

Con relativa frecuencia aparecen en prensa noticias sobre demandas judiciales entre empleados y empresas por violaciones deliberadas de la privacidad en el correo electrónico, pero poco se habla de los posibles problemas de privacidad que surgen fortuitamente durante el análisis que realizan los sistemas de detección de intrusos (IDS).

Para los no familiarizados con el término —aunque imagino que habrá pocos—, un IDS es un equipo que analiza el tráfico de red, generalmente entre Internet y la red corporativa, aunque puede ser ubicado en cualquier otro punto de la estructura de red. Cualquier comunicación sospechosa de ser un ataque, virus, o comunicación ilícita es registrada para ser analizada por técnicos, quienes se encargan de diferenciar los falsos positivos —comunicaciones válidas que parecen ataques— de ataques reales. Puesto que estamos hablando de un sniffer, al monitorizar el tráfico es posible interceptar comunicaciones en texto plano que contengan información sensible, como pueden ser comunicaciones personales, detalles de navegación o contraseñas.

El pasado viernes, estuvimos participando en una sesión sobre “ITIL y Seguridad en la práctica”, organizada por nuestros amigos de Tecnofor en Madrid. Asistieron más de cincuenta directivos de entidades públicas y privadas de prestigio. Nos acompañó Manuel Mata, director de TI de Ciudad de las Artes y las Ciencias de Valencia, a quien desde aquí queremos agradecer el favor de su participación y su interés y esfuerzo.

Tras una introducción de Marlon Molina (Tecnofor), José Antonio Espinal (Tecnofor) presentó los referenciales de base de ITIL y los SGSI, preparando el terreno para los casos prácticos presentados a continuación por José Rosell (S2 Grupo) y Manuel Mata (CAC).

(Para hoy miércoles, una entrada de uno de nuestros colaboradores habituales, Francisco Benet, elaborada conjuntamente con Manuel Benet)

La suplantación de identidad podría definirse según la RAE como una combinación de suplantar e identidad. Veamos qué dice la RAE al respecto:

Cuando comencé mi carrera profesional como técnico de Sistemas hace algo más de nueve años (hay que ver cómo pasa el tiempo), una de las primeras responsabilidades que me “cayó” encima en mi anterior empresa fue la gestión del sistema de monitorización de la infraestructura TIC propia y de clientes. La situación entonces era muy diferente de la actual. Nagios acababa de nacer a partir de NetSaint, y la madurez de este tipo de software distaba mucho de ser la actual; el sistema que utilizábamos (Big Brother) no era el colmo de la usabilidad, aunque su interfaz era extremadamente intuitivo. Los monitores eran bastante más rudimentarios que hoy en día, pero aun así, conseguíamos saber si las cosas funcionaban, por la cuenta que nos traía; teniendo en cuenta que por aquel entonces alojábamos la web de varios clientes importantes, una caída solía ser la antesala de problemas, así que si además no la detectábamos, imagínense. En definitiva, puede decirse que durante un buen puñado de años, tanto en aquella empresa como en la actual, mis andanzas como informático han estado ligadas entre otras cosas a gestionar sistemas de monitorización.

Aunque hoy en día aún es posible encontrar alguna empresa sin ningún sistema de monitorización TIC básico o uno que “ahí está” pero nadie mantiene ni “escucha”, las cosas han cambiado mucho. Ha habido una mejora significativa al menos en el primer paso: la detección de las incidencias. Ahora ya nadie se extraña de que sea necesario un sistema de monitorización TIC que al menos nos avise de cuándo el servidor de correo ha dejado de funcionar y así evitar los gritos de la alta dirección. Podría decirse que casi nos felicitamos por ello, como si eso fuese un gran logro. Vamos a dejar de lado aspectos de monitorización más complejos y todo el capítulo de gestión, tratamiento de las incidencias y análisis histórico; aunque debería ser inseparable de lo anterior, seguramente eso es demasiado.

(Comenzamos la semana con la colaboración de un amigo al que muchas veces hemos invitado a escribir, pero hasta ahora no se había decidido. Nos ha pedido, no obstante, que desea firmar anónimamente y que su colaboración aparezca firmada con el pseudónimo Walt Kowalsky. Esperamos que les parezca interesante)

Llevo tiempo siguiendo este interesante blog, que se ha convertido en uno de mis favoritos y después de un tiempo queriendo aportar mi granito de arena, me he lanzado a la piscina y he preparado la siguiente colaboración que espero que les sea de agrado.

A pesar del título del post, no esperen un enfrentamiento a lo Quevedo-Gongora, puesto que por ahí no van los tiros. Voy a ponerles en situación comenzando con el recurso fácil de la pregunta retórica: ¿se han copiado de ustedes en algún examen? Seguramente contestarán que sí y si no me equivoco muchas veces habrá sido de mutuo acuerdo. Pero, ¿se han copiado de ustedes sin su permiso? Si ha sido así traten de recordar la sensación de aquel momento. Llevaban semanas preparando ese examen concienzudamente, noches sin dormir, cafeína recorriendo su torrente sanguíneo para al final tener la certeza de que el día del examen la cosa va a ir bien y que pasaremos la prueba con nota. Entran al examen y comprueban que a su lado se sienta aquel compañero que únicamente vieron el primer día de clase, aquel que se dedicó a salir todos los jueves y a llegar a laboratorio para que el compañero le haga las prácticas. Comienza el examen y todo marcha de acuerdo con su plan maestro, pero entonces se dan cuenta de que el compañero de al lado está copiando descaradamente nuestro examen… Se acaba el examen y unas semanas más tarde cuando salen las notas comprueban que aquel jeta ha sacado casi la misma nota que nosotros, pero sin asistir a clase, SIN DEDICARLE RECURSOS. En ese momento piensan en todo el tiempo y esfuerzo que han dedicado a prepararse para aprobar ese examen, y lo poco que ha invertido nuestro compañero en aprobar, y piensan que la vida no es justa.

Alguien les susurra C´est la vie….

(Para acabar la semana en que hemos superado los 1000 suscriptores al feed, hoy tenemos una colaboración de Rafael García, amigo, antiguo colaborador de S2 Grupo y con extensos conocimientos y experiencia en la gestión de centros de proceso de datos, como muestra en su blog. Esperamos que les guste la entrada tanto como a nosotros; por lo demás, pasen un buen fin de semana, nosotros nos vamos hasta el lunes, aunque esporádicamente puede que aparezcamos por “el” Twitter)

Hace casi un año, el pasado 28 de Febrero de 2009 YouTube dejó de funcionar durante 2 horas. La incidencia —una incidencia de su conectividad— no se debió ni a la falta de redundancia de sus infraestructuras, ni a un fallo coordinado de todos sus proveedores, ni a un apagón simultáneo de todos sus centros de datos; ni siquiera al súbito interés simultáneo y mundial por el último vídeo de la Obama girl. YouTube dejó de funcionar debido al secuestro de parte de su direccionamiento IP por parte del operador Pakistan Telecom. ¿Secuestro? Sí, secuestro o suplantación del direccionamiento IP, algo tan antiguo como el propio protocolo BGP.

BGP4 (RFC 1771 y RFC 1772) es el protocolo que se utiliza para intercambiar tráfico entre los proveedores de servicios de Internet. Sus funciones son bastante simples: básicamente permite que los sistemas autónomos (AS) —las subdivisones organizativas que gestionan los prefijos de enrutamiento en Internet, habitualmente un ISP— comuniquen a otros sistemas autónomos cómo alcanzar redes en Internet. Específicamente BGPv4 intercambia prefijos de direcciones de Internet seguidas de los identificadores de los sistemas autónomos a través de los cuales se alcanza dicho direccionamiento. Todos los ASs intercambian esta información entre ellos asumiendo que es correcta. BGP, aunque permite implementar políticas sobre los prefijos que anuncia o deja de anunciar, no tiene ningún mecanismo para saber si la información de sus tablas de enrutamiento es válida y si realmente se la está suministrando quien debe suministrársela. Este funcionamiento se denomina confianza transitiva, vamos, que si me creo lo que me dices me estoy creyendo lo que a tí te dicen todos tus vecinos y los míos te creerán. Transitive faith podrían haberle puesto.