Sobre cerdos y gallinas

Aunque muy conocida la fábula o chiste del cerdo y la gallina, lo voy a reproducir en versión libre, para que sirva de introducción para el que no lo conozca.

“Se encuentran un cerdo y una gallina y deciden abrir un restaurante.

El cerdo dice: ¿como llamaremos al restaurante?

La gallina responde: Huevos con bacon

El cerdo contesta: No me parece justo, yo estaría comprometido mientras que tú solo estarías involucrada”

Los roles “cerdo” y “gallina” están presentes en todos los ámbitos de la vida, no solamente en SCRUM :-). En todas las comunidades, sociedades, equipos y convivencias, hay roles cerdo y gallina en mayor o menor medida.

La diferencia entre estar involucrado o comprometido, que a priori, se podría asociar al nivel de riesgo que se toma al participar en un proyecto; laboral o sencillamente de relación, en muchos casos se vuelve algo absolutamente subjetivo y cada uno cree ocupar un rol, que no es visto así por los demás.

Tenemos como “gallinas innatas” a aquellas personas que que se dedican a “estar”; en algunos casos, solo a “figurar”, que arriman el hombro en contadas ocasiones y solo, cuando no queda más remedio. Algunos de estos “fasiánidos”, suelen tener una habilidad especial, para aparecer cuando ha finalizado el trabajo.

Tenemos como “cerdos de vocación”, a aquellas personas que lo dan todo, que no reparan en sacrificios para conseguir el buen fin del proyecto y con los que puedes contar cuando se ponen las cosas feas. Este tipo de “suidos”, a menudo se ven eclipsados por los “fasianidos” cuando las cosas salen bien y cargan con las culpas cuando la cosa se tuerce.

Esta categorización puede parecer un poco extremista y de hecho, lo es, pero ¿le suena a alguien?. La realidad no es blanca ni negra y oscila sobre la escala de grises con el tiempo.

¿podemos elegir nuestro rol? . No, generalmente nos viene impuesto en cada caso, además no suele ser buena idea cambiarlo, no suele acarrear buenos resultados. Cada momento y cada escenario son una partida distinta, solo puedes jugar las cartas o pasar la mano, habrá otras.

El grado de implicación y compromiso es difícil de medir, además, bajo determinadas circunstancias, todos tendemos a pensar que los demás son las “gallinas” y nosotros los “cerdos” y esto en realidad no es más que un reflejo de nuestra propia frustración.

El cerdo y la gallina, sí pueden poner un restaurante juntos, solo hace falta cambiarle el nombre a "La tortilla de patata".

Las nubes también se caen II

Habrá que esperar algunas semanas más, antes de sacar conclusiones acerca de como va a afectar a Amazon y al Cloud Computing en general, la caída de los servicios de Amazon (Las nubes también se caen), pero de momento no parece que vaya a ser una catástrofe para Amazon, ni que esto vaya a provocar un cambio de tendencia en la adopción del Cloud Computing por parte de las empresas.

Lo que si es seguro, es que este "incidente", va a marcar un punto de inflexión en muchos aspectos relacionados con el Cloud Computing.

Amazon tendrá que hacer algo más que pedir disculpas a sus clientes y regalarles 10 días gratis de servicios. Tendrá que volver a ganar la confianza perdida y para ello deberá actuar en varias líneas de mejora.

Evidentemente, deberá poner el foco en como mejorar los procesos de mantenimiento, automatización de tareas, supervisión de procesos, monitorizaciones, etc. ya que en este caso han sido los causantes del problema.

Desde el punto de vista técnico, deberá replantearse el modelo de replicación de datos entre Zonas. Está claro que los mecanismos de aislamiento entre Zonas de Disponibilidad, no han sido lo suficientemente efectivos. El factor comunicaciones ha sido determinante.

En cuanto a comunicación y transparencia también deberá aprender de lo ocurrido. Desde siempre han sido bastante reacios a dar más información y explicaciones que las estrictamente necesarias, pero tiene que pensar que la información a sus clientes ante una caída de este tipo, puede ser beneficiosa en el sentido de que los propios clientes pueden colaborar en restaurar la situación global, ayudando a restaurar la suya propia.

El SLA que proporciona Amazon no está a la altura de las circunstancias. Cualquier empresa que decida externalizar los servicios con un tercero, negociará un SLA con su proveedor. En este caso Amazon no puede negociar con cada cliente un SLA particular ¿o si?, pero lo que si puede hacer, es proporcionar un SLA de verdad, donde se garantice algo más que un porcentaje de up-time.

Pero no solamente Amazon se deberá poner las pilas, y cuando digo Amazon, quiero decir además Microsoft, Akamai, Google, IBM, etc., sino los propios "usuarios". El proveedor Cloud ofrecerá una serie de ventajas y garantías para asegurar la disponibilidad del servicio, o en su caso, minimizar el impacto de una caída, pero el propio cliente debe hacer lo propio con su modelo de aplicación y despliegue. No es tan sencillo como poner la aplicación "en la nube" y esperar que el proveedor Cloud haga el resto.

El diseño de las aplicaciones, desde el punto de vista de disponibilidad y de seguridad es un aspecto que no va a cubrir en su totalidad el proveedor. Tampoco es que sea algo distinto de lo que se debiera hacer en un modelo on-premise, pero el contexto es diferente y las herramientas de las que dispone el cliente, no son las mismas.

Como se suele decir, "a río revuelto, ganancia de pescadores" y a buen seguro, otros proveedores Cloud, verán en este capítulo, una excelente oportunidad de ampliar su base de clientes, no solo por que abandonen Amazon, sino porque muchos de ellos, o al menos los más importantes, diversificarán sus implementaciones Cloud entre varios proveedores.

Lo que le ha pasado a Amazon, le puede pasar a cualquiera. Mejor dicho, le ha pasado a casi todos, en mayor o menor medida.

En general, no creo que vaya a cambiar nada en cuanto a la estrategia; a nivel de decisión; de movimiento hacia la nube, aunque quizá los modelos híbridos de nube pública y privada ganen posiciones frente al modelo de nube pública en exclusiva. Reddit, uno de los afectados por el "apagón", ya se ha pronunciado en este sentido.

Las nubes también se caen

La semana pasada se produjo la caída de los servicios EC2 de Amazon (Amazon Elastic Compute Cloud), los cuales tardaron varios días en recuperarse al completo. La caída afectó a conocidas empresas como Foursquare, Reddit, Quora o Hootsuite entre otras.

El impacto mediático ha sido notable, sobre todo teniendo en cuenta que en plena efervescencia del Cloud Computing, una caída de este tiempo en un proveedor de la envergadura de Amazon, da argumentos a los detractores del Cloud Computing.

Amazon tiene sus datacenters repartidos en 5 regiones; 2 en EE.UU. (costa este y oeste), uno en Europa (Irlanda) y 2 en Asia (Tokio y Singapur); y cada región se separa varias Zonas de Disponibilidad (AZ – Availability Zone). Cada AZ está aislada de las demás y entre ellas no debe haber puntos comunes de fallo, al menos es lo que publicita Amazon.

Todo comenzó el jueves 21 de abril, durante una operación rutinaria en la AZ del Norte de Virginia en la Región Este de EE.UU.. Por un error, se desvió el tráfico de uno de los routers a la red de backup, que dispone de menos capacidad y una mayor latencia. Esto provocó una atasco que se se convirtió en una reacción en cadena, primero en nodos EBS (Elastic Block Store), después en las API de control de los cluster EBS, el RDS (Relational Database Service), que se soporta en el EBS. Esto acabó afectando a todas las AZ's de la misma región.

Amazon no proporciona un servicio de replicación entre regiones, aunque si entre AZ's, a cambio, proporciona un API para que cada usuario pueda gestionar la tolerancia a fallos entre regiones. Aunque en menor medida, por este motivo otras regiones tuvieron pequeños “atascos”, que Amazon lo cuantifica en un 0,07%.

Muchos clientes, se han quejado de la poca transparencia e información que proporcionó Amazon durante la caída. En un principio la única información fue la que proporcionaba el monitor de AWS  (Amazon Web Services). De hecho, algunos clientes indican que si hubieran dispuesto de más información acerca de los motivos, hubieran podido recuperar antes sus sistemas.

Algunas quejas, como las de Justin Santa Barbara (Why the sky is falling), fundador y CEO de FathomDB, van en el sentido de que AWS no cumple sus propias especificaciones y ha roto sus promesas de disponibilidad dentro de las AZ's, aún cuando los sistemas desplegados siguieran las especificaciones de Amazon al respecto.

Pero no todo el mundo se ha quejado del incidente, de hecho hay quién indica que el perjuicio sufrido está compensado con las prestaciones y el precio que Amazon proporciona a sus clientes.

La verdad es que no todos los clientes de Amazon en la AZ afectada, que por cierto, es la más concurrida, se han visto afectados, o al menos de la misma forma. En concreto NetFlix o Twilio, no sufrieron las consecuencias.

En el caso de Twilio; según explica Evan Cook en su blog, el diseño de sus aplicaciones, el poco acoplamiento entre ellas y la distribución de los servicios, les ha permitido no verse afectados por esta caída. Quizá Amazon quiera incluir algunas de las recomendaciones que hace Evan, en sus propuestas de despliegue.

Después de todo el chaparrón, Amazon ha publicado un informe, que lo han denominado “post-mortem” explicando lo ocurrido y donde finalmente dice que “recompensará” a los clientes con instancias EC2 en la AZ afectada, con el equivalente a 10 días del consumo de los volúmenes EBS, instancias EC2 e instancias RDS, que tenían contratados en el momento de la caída.

Curiosamente, dado que la caída del servicio ha sido de 4 días, y teniendo en cuenta que; tal y como publican en el FAQ, el up-time que garantiza es del 99,95%, legalmente no se han incumplido los términos de SLA.

Ahora es tiempo de sacar conclusiones, no solamente por parte de Amazon, sino por parte de proveedores de Cloud Computing y de usuarios, actuales y futuros. Esto debe servir para aprender y mejorar los servicios y aplicaciones que corren en este modelo. En cierto modo, es bueno que pasen estas cosas.

El rastreo de iPhone y Android

Hace unos días se conocía que los iPhone e iPad  de Apple guardaban un registro de las posiciones de los usuarios (más bien de sus teléfonos) y que por si fuera poco, esos datos se registraban en un archivo sin protección. Unos días más tarde, conocemos por un artículo en The Wall Street Journal, que Google hace lo mismo con sus teléfonos Android .

El tema ha creado bastante revuelo desde que se ha conocido. Corea del Sur ha pedido explicaciones a Google y el senador de EE.UU. Al Franken, ha hecho lo propio con Apple, escribiendo una carta a Steve Jobs, en la que le pide respuestas a una serie de preguntas sobre el tema.

En el caso de Apple, se disculpan diciendo que los datos de localización solo se registran cuando el usuario utiliza una aplicación que requiere localización, después los datos se envían encriptados cada 12 horas a Apple. 

En el caso de Android, la información se recoge cada pocos segundos y se envía varias veces por hora a los servidores de Google, con la diferencia de que en este caso, los datos se relacionan con el identificador único del teléfono. Google se disculpa diciendo que lo hace bajo el consentimiento del usuario.

Google y Apple, no pierden tiempo en tomar posiciones en los servicios de localización y coger su trozo de pastel en este mercado, en el que según Gartner, alcanzará los 8,3 billones (US) de dólares .

A mi personalmente, no me apetece que alguien pueda saber donde he estado en los últimos meses, aunque es por el mismo motivo por el que no tengo un perfil de Facebook donde publico las fotos de mis últimas vacaciones.

Como de todo tiene que haber en este mundo, hay quién a todo esto le encuentra la gracia y lejos de molestarles el asunto, se divierten revisando sus itinerarios y como no podía ser de otra forma, publicándolos en Facebook o cualquier otra red social, nada nuevo teniendo en cuenta el éxito de Foursquare o Facebook Places.

Al poco de conocerse la noticia de que los iPhone guardaban los datos de localización en un archivo desprotegido, estaba disponible la aplicación iPhone Tracker, una aplicación de código abierto, que permite visualizar los sitios en los que se ha estado en los últimos meses, desde que comenzó la grabación de los datos.

Si los datos de geolocalización son de fácil acceso y a eso le sumamos que los ataques dirigidos cada vez son más frecuentes y precisos, no será de extrañar que ya esté en circulación algún tipo de malware específico para iPhone, encaminado a saber donde han estado ciertas personas en los últimos meses.

En el caso de iPhone, también existe una aplicación llamada Untrackerd que borra constantemente el archivo donde se guardan estos controvertidos datos.

Releyendo Scrum y XP desde las Trincheras

El otro día se me ocurrió volver a leer el clásico de la literatura Scrum “Scrum and XP from the Trenches”, con el objetivo de comparar la aplicación de Scrum que se comenta en el libro y la que practicamos en mi organización. 

Cuando leí el libro por primera vez, antes de comenzar a aplicar Scrum, a medida que leía el libro trataba de prestar atención en aquellos aspectos en los que el autor ponía más énfasis, suponiendo que una vez inmerso en la práctica, esas cuestiones serían a las que más importancia darle. De forma inconsciente, fui haciendo una selección de estos aspectos para quedarme con un top-10.

Después de volver a leer el libro, e intentar hacer un top-10, la verdad es que lo he tenido más difícil, ya que algunas cuestiones que pasé por alto en su momento, han adquirido ahora una especial relevancia.

En el libro se insiste en que no hay una regla única para aplicar Scrum y que se debe probar con diferentes formas de hacer las cosas, hasta dar con la que mejor se ajusta al contexto donde se aplicará. En efecto eso es así, tanto que incluso si en la primera iteración de su aplicación nos encontramos cómodos, debemos probar a hacer cambios, incluso a sabiendas de que alguno de los cambios que hagamos será a peor, pero eso también sirve para encontrar el modelo óptimo para tu caso.

No se debe tener miedo a cambiar las cosas incluso si creemos que lo que hacemos ya está bastante bien. La mejora continua, debe ser una constante.

Volviendo al tema del libro, uno de los aspectos a los que se le da mucha importancia, pero que yo no supe ver en su plenitud tras la primera lectura, es el conocimiento de la velocidad de los equipos. Al principio pensé que era un indicador más, pero he observado que es vital en dos aspectos que inicialmente no di demasiada importancia: la reducción del riesgo y la mejora continua.

Reducción del riesgo: La estimación y la planificación de un proyecto, no tendrá base objetiva si no conocemos este dato y por lo tanto, estaremos más expuestos a incurrir en retrasos y sobrecostes, sobre todo cuanto más grande sea el proyecto.

Mejora continua: La evolución de la velocidad de los equipos, será un claro indicador de la madurez de los equipos, y como eso se traduce en una mejora de sus resultados. Si analizamos los picos y valles en la evolución de las velocidades y los contrastamos con acciones o cambios introducidos en los equipos, podremos sacar jugosas conclusiones.

Otro aspecto que ha adquirido una especial relevancia para mi, ha sido la importancia del artefacto “Sprint Burn Down Chart”, sobre todo si comparamos la evolución de estas gráficas a lo largo de los distintos Sprints. El seguimiento diario de su evolución permite aprender mucho de como estamos distribuyendo y abordando las historias. No hace falta asistir a todos los “Daily” para darse cuenta mirando este gráfico, de que algunos miembros del equipo repiten durante demasiados días “Sigo trabajando en X”.

La verdad es que ha sido un buen ejercicio leer de nuevo este libro, ha sido como juntarse con algún colega para compartir experiencias sobre Scrum.

No se si ya lo ha dicho alguien antes, pero se me ocurre que un buen consejo para finalizar, sería: “Se práctico y no escatimes esfuerzos en ahorrar trabajo”.

Si alguien no conoce el libro y está interesado en su lectura, se puede descargar de Internet en formato PDF, tanto en inglés como en castellano. Es una lectura amena y no lleva demasiado tiempo leerlo.

No pongo ningún enlace ya que se puede encontrar con facilidad y existen numerosos sitios de descarga.

20 años de Linux

Para algunos será una eternidad y para otros un suspiro, pero la verdad es que ya han pasado 20 años desde que el señor Linus Benedict Torvalds escribió el ya célebre mensaje de correo en el que anunciaba la creación de lo que más tarde, todos conoceríamos como Linux:

“Hello everybody out there… I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) … It is NOT portable …and it probably will never support anything other than AT-harddisks, as that’s all I have :-(”

En aquellos momentos, allá por abril de 1991, cuando Linus escribía este mensaje, no podía ni imaginarse la repercusión de lo que estaba gestando, así como tampoco lo equivocado que estaba cuando pensaba que nunca soportaría otro hardware más allá de su 386.

Evidentemente  hay mucha gente que no sabe que es esto del Linux, pero sin darse cuenta, en muchos casos lo están usando sin saberlo, en su teléfono móvil, en su cámara fotográfica o en el mismo cajero automático.

Aunque no sean los hitos más importantes en la historia de Linux, me gustaría reseñar unos pocos, que por diferentes motivos, me parecen interesantes:

• Agosto de 1991- El nacimiento: se publica la primera versión del kernel de Linux
• Abril de 1993-La primera apuesta por Linux: aparece Slackware la primera distribución de Linux y la más antigua ya que aún existe.
• 1996-Nace TUX:  Larry Ewing crea TUX, el pingüino símbolo de Linux.
• 2003-La apuesta de los gigantes: IBM sorprende al mundo con el anuncio de IBM-Linux durante la Super Bowl.
• 2010-Se abre una nueva era para Linux: Google crea Android, basado en el kernel de Linux

Aunque no lo podría catalogar como un hito, entre 2009 y 2010 la distribución Ubuntu, que aunque lleva en la calle desde finales de 2004, da un salto cualitativo acercando Linux al usuario de a pié, haciendo una distribución más fácil de usar y más amigable que otras anteriores, de hecho, actualmente tiene una cuota del 50% entre los usuarios de Linux.

Durante estos 20 años ha habido luces y sombras, pero Linux se ha mantenido firme, buscando su sitio poco a poco, a pesar de detractores como el propio CEO de Microsoft, Steve Ballmer, quién llegó a calificarlo en 2001 como:  "Linux es un cáncer que se pega a la propiedad intelectual"

A lo largo de estos 20 años, hemos ido viendo como Linux iba cambiando, algunas veces incluso a peor; el propio Linus llegó a decir en algún momento, que KDE era un desastre; pero poco a poco ha ido ganando posiciones en todos los sentidos.

La mayoría de los sitios web en Internet utilizan servidores Linux, los grandes superordenadores también, pero el desktop siempre se le ha atragantado. En este sentido Ubuntu y Android están consiguiendo cambiar la tendencia. ¿El truco?, hacer las cosas más fáciles para el usuario, esa siempre ha sido la clave del éxito. No solo sirve disponer de miles de aplicaciones gratuitas para Linux si estas son difíciles de instalar, de actualizar o de usar.

En alguna entrevista, Linus ha reconocido que Ubuntu ha hecho un gran aporte al mundo Linux por su sencillez de uso para el usuario final, aunque por otro lado también reconoce que no es cómodo para los desarrolladores del Kernel, pero ¿Cuántos desarroladores de Kernel hay?.

Donde Linus no tiene dudas es con Android, ¡está encantado!

Aunque habrá que esperar hasta agosto… Feliz Cumpleaños, Linux!!!

Factores clave en la adopción de Scrum por las empresas de TI

Las metodologías ágiles en general y Scrum en particular, están gozando de creciente aceptación y aplicación en nuestras empresas de TI. Aunque estas metodologías no son nuevas, si es verdad que en los últimos 2 o 3 años se han percibido sus beneficios de forma sustancial, todo ello motivado seguramente por aspectos externos como el propio mercado, la crisis económica, etc.

La metodología Scrum tiene unos fundamentos sencillos y aunque a primera vista pueda parecer simple de aplicar y nada nuevo respecto a lo que hemos venido haciendo tiempo atrás, en realidad no es así y aunque sus principios son pocos y sencillos, es imperativo seguirlos para que la aplicación de la metodología consiga el objetivo.

Sin entrar en detalle de como se aplica la metodología, que significan sus roles, artefactos, métricas, etc., si me gustaría señalar algunas cuestiones clave para la aplicación de Scrum y sobre las cuales merece la pena reflexionar antes de adoptar esta metodología.

En cualquier caso, antes de plantearse adoptar Scrum como metodología de trabajo, habrá que pararse a pensar si cumplimos ciertos requisitos o qué podemos hacer para cumplirlos antes de comenzar.

Aunque hay muchos aspectos importantes a valorar, como por ejemplo la comunicación, la implicación del cliente, la estabilidad, etc., quiero centrarme en dos que para mí tienen una especial relevancia: El Cambio organizacional y el Compromiso del equipo.

El cambio organizacional

Por lo general, en la mayoría de las empresas, existe un organigrama demasiado jerarquizado, que no encaja demasiado en la definición de roles de Scrum. En este sentido, la dirección de la empresa debe remodelar la estructura para “achatar la pirámide”.

El cambio organizacional, es quizá el más controvertido a la hora de aplicarlo. Ya no tiene sentido hablar de Jefe de Departamento, Jefe de Proyecto, Analista Funcional, Analista Programador, Programador Senior, etc. donde cada uno parecía tener sus funciones acotadas y de la misma forma que representaba la estructura, se procedía a un trabajo en cadena, donde cada uno hacía una parte y se la pasaba al siguiente. Esto en Scrum ya no tiene sentido.

Es un error habitual, es asimilar el rol tradicional de Project Manager al de Scrum Master. Un Project Manager puede convertirse en Scrum Master, si sus skills le permiten ser un facilitador, pero ya no tiene por que ser un buen gestor. Ahora el equipo se autogestiona.

Es complicado para la empresa, acometer un cambio en la estructura, pero seguramente es más complicado para las personas, que de repente pierden su “status” y se disuelven en un “Scrum Team”. Esto hay que saberlo gestionar adecuadamente para que se traduzca en una oportunidad en vez de una amenaza para las personas.

El compromiso del equipo

En Scrum, el equipo y el trabajo en equipo adquieren una nueva dimensión, ahora el equipo es un ente con atribuciones que hasta ahora, solo recaían en ciertas personas en particular. Ahora el equipo se autogestiona y toma sus propias decisiones.

El objetivo es pensar en el equipo como un ente único, pero queramos o no, los equipos los forman las personas y las personas tienen sus virtudes y sus defectos.

Las personas brillantes son siempre bienvenidas en todos los equipos, pero el problema surge cuando alguna de estas personas por ego profesional o personal, trata de imponer sus criterios o manipular al resto del equipo. Las individualidades deben supeditarse al equipo y el éxito o el fracaso es siempre del equipo, no de las personas por separado.

Cualquier persona, siempre tiene algo que aportar al equipo, solamente es cuestión de buscar que es y aprovecharlo. No sirve dejarse llevar, siempre hay que aportar.

Dentro del equipo, las personas deben confiar unas en otras y ser transparentes en su trabajo, si no es así, deberán cambiar algunos de sus anteriores hábitos.

El cambio de mentalidad puede llegar a ser un problema si no se gestiona adecuadamente por parte de la organización. En este sentido, será preciso hacer una labor de mentalización y convencimiento para que las personas tengan claro que su apuesta debe ser por el equipo.

En casa de herrero, cuchillo de palo

Últimamente se ve con demasiada frecuencia que empresas de seguridad son atacadas o tienen algún tipo de problema relacionado, precisamente, con la seguridad.

Hay otros casos, como el de McAfee, en los que teniendo problemas de seguridad y siendo conscientes de ello, hacen oídos sordos incluso cuando desde fuera de la organización, se les advierte de tales carencias.

Un grupo de “hackers éticos” denominado YGN Ethical Hacker Group, descubrió que la algunos sitios web de McAfee presentaba algunas vulnerabilidades y que estas podrían ser explotadas a través de ataques del tipo XSS (Cross-site scripting), utilizados habitualmente en phising e inyección de código de scripting como javascript, VBScript, PHP,etc.

YGN advirtió a McAfee de tales vulnerabilidades el 10 de febrero y dos días más tarde McAfee respondió diciendo que ya conocían el problema y que estaban trabajando el ello para resolver la incidencia lo antes posible, pero el día 27 de marzo, mes y medio después, una nueva comprobación de YGN demuestra que aún no han sido solucionados dichos problemas. El mismo día 27, YGN decide publicar la información acerca de las vulnerabilidades descubiertas. Que descuido!.

La vulnerabilidad podría haber sido usada, entre otros en download.mcafee.com, para provocar que sus usuarios se descargaran, por ejemplo, una demo o una beta de sus productos infectada, evidentemente desde otro sitio y sin saberlo.

La compañía ha respondido diciendo que estas vulnerabilidades no exponen información alguna de clientes, partners o de la misma compañía, que por supuesto no afecta a sus productos de seguridad y que además, tampoco han observado que se hayan explotado estas vulnerabilidades. Quizá piensen que así sus clientes se quedan más tranquilos!.

McAfee ya tuvo problemas de este tipo en el pasado, en 2008, 2009 y 2010, pero parece que no han aprendido la lección.

Lo que realmente me llama la atención, no es que tengan este tipo de vulnerabilidades, que cualquiera las puede tener, sino que después de ser notificados, no hayan hecho nada al respecto, sobre todo sabiendo que si no se corrige, la información se va a hacer pública y eso cuando menos, no es beneficioso para su imagen.

Si McAfee tiene un servicio orientado a empresas, que se dedica a identificar problemas de seguridad en sus sites, solo se me ocurre un corolario para el post: En casa de herrero, cuchillo de palo.

Certificados digitales falsos de Microsoft, Google, Skype, Yahoo! y Mozilla

La semana pasada saltó a los medios la noticia de que uno de los Partners de Comodo habría sido comprometido en su seguridad y se habría conseguido la emisión de certificados SSL falsos, pero que a todos los efectos, serían dados por válidos en cualquier navegador.

El incidente quizá hubiera pasado sin mayor notoriedad, si no hubiera sido porque los certificados falsos correspondían a sitios web de empresas tan relevantes como Microsoft, Google, Skype, Yahoo! y Mozilla. En total 9 certificados falsos pertenecientes a estas 5 empresas.

En este caso, parece que Iran devuelve la pelota del Stuxnet, ya que las IP desde las que se realizó el ataque a los servidores, provenían de este país.

Desde hace dos o tres años, este tipo de actuaciones es cada vez más frecuente, sobre todo para su uso en malware y así dificultar su detección, como ha ocurrido con Zeus o Stuxnet, aunque en este último caso, el certificado aunque robado, era válido.

El uso de estos certificados SSL falsos, permitiría realizar ataques del tipo MitM (Man in the Middle), donde el acceso mediante el protocolo seguro SSL (Secure Sockets Layer) a una web falsa, quedaría inadvertido por el usuario, así como la sustitución del contenido que percibe el usuario de la web real por uno alterado.

Este tipo de prácticas de filtrado de contenidos, bloqueo o suplantación, a través del uso de Proxys Transparentes viene siendo aplicada con asiduidad por gobiernos como China o Iran, donde la libertad de expresión en Internet está muy restringida.

En los casos en los que se detecta el uso de estos certificados falsos, como ha sido este, la autoridad certificadora procede a la revocación de los certificados, pero esto no tiene por que ser la solución completa e inmediata al problema.

La comprobación de certificados revocados, se puede hacer a través de CRL (Certificate Revocation List) o a través del acceso a servidores OCSP (Online Certificate Status Protocol), pero en el primer caso, las CRL se descargan y procesan en local, por lo que si no están actualizadas, su efectividad es prácticamente nula.

En el caso del acceso a los OCSP, dependerá de cómo se comporten los navegadores respecto a este tipo de consultas, así como la configuración que tenga el usuario en su navegador. Por ejemplo Internet Explorer 8 y Safari, no hacen comprobaciones OCSP por defecto y en Firefox, aunque si se hace, en el caso de que falle la consulta, no está activada por defecto la opción de que se de por inválido el certificado.

En el caso de los certificados falsos de Comodo, Microsoft, Mozilla y Google, han publicado parches de seguridad para sus respectivos navegadores y así evitar el uso de estos certificados falsos.

¿Es posible una Ciberguerra?

En último Black Hat Europa que se ha celebrado en Barcelona este mes, una de las ponencias más esperadas fue la de Bruce Shneier; reputado criptógrafo y experto en seguridad; quien quitaba dramatismo a la posibilidad de una Ciberguerra, diciendo “Los gobiernos exageran sobre la Ciberguerra…”

No voy a poner en duda los comentarios y argumentos de tan reputada autoridad, pero si me voy a permitir hacer algunos propios, al respecto de este tema.

Si tratamos de traducir lo que significa Ciberguerra, sería algo así como una guerra que se libra en el Ciberespacio, y es sobre lo que podemos entender como Ciberguerra, de lo que quiero comentar.

Si atendemos al sentido de la palabra Ciberguerra, cuando se refiere a un enfrentamiento entre dos o varias naciones, lo primero que me viene a la cabeza es la historia de Stuxnet y las centrifugadoras de las centrales nucleares iraníes, que aunque no se ha acabado de aclarar la cuestión, parece que fue obra de Israel y Estados Unidos.

Cuando en un asunto como el del Stuxnet, aparecen estados por detrás, ¿eso es ciberguerra?, estrictamente yo no lo llamaría así, aunque habrá opiniones para todos los gustos. Yo lo catalogaría más próximo al ámbito del ciberespionaje o cibersabotaje, si se me permite.

Si atendemos al sentido de la palabra guerra, cuando se refiere a un enfrentamiento entre dos bandos (no estados o partes de él), y esos bandos, aunque definidos, no son concretos; es decir, no podemos concretar la identidad de uno de ellos o de ambos, llegamos al grupo de los Ciberataques (por mantener la terminología), que tampoco sería Ciberguerra, sino ataques puntuales con objetivos muy focalizados.

Realmente, si me abstraigo de consideraciones formales, y desde la perspectiva puramente emotiva, me atrevería a decir que ya estamos en una Ciberguerra, donde no sabemos quienes son nuestros enemigos, ni donde están, solo conocemos; y no siempre; sus motivaciones: robo, extorsión, desestabilización, espionaje, sabotaje, etc.

Si nos referimos a la posibilidad de una Ciberguerra, abstrayéndonos de quienes son las partes beligerantes y nos centramos en los efectos de la contienda, como impacto, alcance, perdurabilidad, etc., podemos concretar un poco más y analizar los riesgos de que esto ocurra, conjugando una serie de variables y datos más o menos objetivos.

Amplitud del objetivo

Muy pocos Ciberataques individuales, tienen la capacidad de crear una conmoción mundial, y más aún que esta pueda perdurar en el tiempo, más allá de unas pocas horas o días, afectando a infraestructuras civiles o militares de diferentes estados.

Hay que tener en cuenta además, que los sistemas informáticos críticos están protegidos ante eventualidades de este tipo; aunque esto no quiere decir que sean invulnerables; y que por lo general operan sobre redes privadas de difícil acceso.

Perdurabilidad

La mayoría de los ataques, se aprovechan de debilidades y fallos de seguridad no conocidos, en los Sistemas Operativos y Aplicaciones, los llamados "zero-day exploits". Habitualmente la respuesta de los fabricantes de software, es rápida y a través de los diferentes equipos CERT (Computer Emergency Response Team), se coordinan para dar una respuesta rápida y eficaz ante este tipo de incidentes, involucrando instituciones civiles y gubernamentales, como por ejemplo el US-CERT.

Ataques oportunistas

Aunque no hay constancia de que haya ocurrido nunca, se podría dar el caso que tras una catástrofe convencional, como podría ser el caso de Japón en estos momentos, se aprovechara la ocasión para realizar ataques a los puntos más débiles afectados por la catástrofe,  pero esto es poco probable que ocurra.

Conclusión

Por lo general, todas o casi todas las guerras a lo largo de la historia, aún cuando las motivaciones fueran diferentes, han tenido un componente común y este ha sido la territorialidad, con el objetivo de ocupar o mantener posiciones geoestratégicas, recursos naturales, etc. En el caso de una Ciberguerra, no es fácil de cubrir este tipo de objetivos, si no va acompañada del componente físico.

En definitiva, la posibilidad de una guerra exclusivamente “cibernética”, por llamarlo de alguna forma, no es muy probable, pero el uso de Ciberataques como complemento de ataques en el plano físico, no solo será habitual sino que de facto, lo viene siendo desde hace mucho tiempo, en sus diferentes formas. Solo por poner algunos ejemplos, se han utilizado estos métodos combinados, durante la guerra de Irak en 2003 y en el conflicto de Georgia y Ossetia del sur en 2008.